Re: [PATCH v4] test/py: net_boot: Add test cases for net boot

2024-05-06 Thread Love Kumar




On 04/05/24 1:48 am, Tom Rini wrote:

On Fri, May 03, 2024 at 05:39:46PM +0530, Love Kumar wrote:


Add tests for booting image using tftpboot/pxe boot commands, tftpboot
boot case loads the FIT image into DDR and boots using bootm command
whereas pxe boot cases downloads the pxe configuration file from the
TFTP server and interprets it to boot the images mentioned in the pxe
configurations file.
This test relies on boardenv_* containing configuration values including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
boot log pattern value is matched. For example, if the parameter
'pattern' is defined as 'login:', it will boot till login prompt.

Signed-off-by: Love Kumar 


I'm not quite sure where the problem is, next. After enabling FIT image
support in my build so I can use the image I have on hand:
U-Boot> tftpboot 20 v6.6/image.fit.nocomp
Waiting for Ethernet connection... done.
Using smsc95xx_eth device
TFTP from server 192.168.1.10; our IP address is 192.168.1.100
Filename 'v6.6/image.fit.nocomp'.
Load address: 0x20
Loading: ##  82 MiB
  3.2 MiB/s
done
Bytes transferred = 85984256 (5200400 hex)
U-Boot> U-Boot> crc32 20 $filesize
CRC32 for 0020 ... 054003ff ==> 754c839a
U-Boot> U-Boot> bootm 20
## Loading kernel from FIT Image at 0020 ...
Could not find configuration node
ERROR -2: can't get kernel image!
U-Boot>

And in u_boot_boardenv_rpi_arm64.py:
env__tftp_boot_test_skip = False

env__net_tftp_bootable_file = {
 'fn': 'v6.6/image.fit.nocomp',
 'addr': 0x0020,
 'size': 85984256,
 'crc32': '754c839a',
 'pattern': 'Linux',
 'config': 'conf-852',
}

But it's not trying to boot conf-852 but instead just passing the
address. This image lacks a default config, which your example has and I
think is why the tests work in your case.



Hi,

Yes, this case expects to have some default config in fit image as it 
uses 'bootm ' command to boot, below change in fit image should work.


configurations {
default = "conf-852";

test_net_tftpboot_boot_config - This case will boot from the given 
config: 'bootm 20#conf-852'


Regards,
Love Kumar


Re: [PATCH 04/16] rockchip: rk3328: Remove redundant device tree files

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

Remove redundant device tree files now that RK3328 boards have been
migrated to use OF_UPSTREAM.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3328-evb.dts  |  289 ---
  arch/arm/dts/rk3328-nanopi-r2c-plus.dts  |   33 -
  arch/arm/dts/rk3328-nanopi-r2c.dts   |   40 -
  arch/arm/dts/rk3328-nanopi-r2s.dts   |  410 
  arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts |   42 -
  arch/arm/dts/rk3328-orangepi-r1-plus.dts |  374 
  arch/arm/dts/rk3328-roc-cc.dts   |  384 
  arch/arm/dts/rk3328-rock-pi-e.dts|  445 
  arch/arm/dts/rk3328-rock64.dts   |  394 
  arch/arm/dts/rk3328.dtsi | 1944 --
  include/dt-bindings/clock/rk3328-cru.h   |  393 
  include/dt-bindings/power/rk3328-power.h |   19 -
  12 files changed, 4767 deletions(-)
  delete mode 100644 arch/arm/dts/rk3328-evb.dts
  delete mode 100644 arch/arm/dts/rk3328-nanopi-r2c-plus.dts
  delete mode 100644 arch/arm/dts/rk3328-nanopi-r2c.dts
  delete mode 100644 arch/arm/dts/rk3328-nanopi-r2s.dts
  delete mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
  delete mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus.dts
  delete mode 100644 arch/arm/dts/rk3328-roc-cc.dts
  delete mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts
  delete mode 100644 arch/arm/dts/rk3328-rock64.dts
  delete mode 100644 arch/arm/dts/rk3328.dtsi
  delete mode 100644 include/dt-bindings/clock/rk3328-cru.h
  delete mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
deleted file mode 100644
index 1eef5504445f..
--- a/arch/arm/dts/rk3328-evb.dts
+++ /dev/null
@@ -1,289 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-#include "rk3328.dtsi"
-
-/ {
-   model = "Rockchip RK3328 EVB";
-   compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
-
-   aliases {
-   ethernet0 = 
-   mmc0 = 
-   mmc1 = 
-   mmc2 = 
-   };
-
-   chosen {
-   stdout-path = "serial2:150n8";
-   };
-
-   dc_12v: dc-12v {
-   compatible = "regulator-fixed";
-   regulator-name = "dc_12v";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <1200>;
-   regulator-max-microvolt = <1200>;
-   };
-
-   sdio_pwrseq: sdio-pwrseq {
-   compatible = "mmc-pwrseq-simple";
-   pinctrl-names = "default";
-   pinctrl-0 = <_enable_h>;
-
-   /*
-* On the module itself this is one of these (depending
-* on the actual card populated):
-* - SDIO_RESET_L_WL_REG_ON
-* - PDN (power down when low)
-*/
-   reset-gpios = < 18 GPIO_ACTIVE_LOW>;
-   };
-
-   vcc_sd: sdmmc-regulator {
-   compatible = "regulator-fixed";
-   gpio = < 30 GPIO_ACTIVE_LOW>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pin>;
-   regulator-name = "vcc_sd";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   vin-supply = <_io>;
-   };
-
-   vcc_sys: vcc-sys {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_sys";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   vin-supply = <_12v>;
-   };
-
-   vcc_phy: vcc-phy-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_phy";
-   regulator-always-on;
-   regulator-boot-on;
-   };
-};
-
- {
-   cpu-supply = <_arm>;
-};
-
- {
-   cpu-supply = <_arm>;
-};
-
- {
-   cpu-supply = <_arm>;
-};
-
- {
-   cpu-supply = <_arm>;
-};
-
- {
-   bus-width = <8>;
-   cap-mmc-highspeed;
-   non-removable;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _bus8>;
-   status = "okay";
-};
-
- {
-   phy-supply = <_phy>;
-   clock_in_out = "output";
-   assigned-clock-rate = <5000>;
-   assigned-clocks = < SCLK_MAC2PHY>;
-   assigned-clock-parents = < SCLK_MAC2PHY_SRC>;
-   status = "okay";
-};
-
- {
-   status = "okay";
-
-   rk805: pmic@18 {
-   compatible = "rockchip,rk805";
-   reg = <0x18>;
-   interrupt-parent = <>;
-   interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
-   #clock-cells = <1>;
-   clock-output-names = "xin32k", "rk805-clkout2";
-

RE: [PATCH] mtd: spi-nor: scale up timeout for full-chip erase

2024-05-06 Thread Abbarapu, Venkatesh
Do you have any update on this change?

Thanks
Venkatesh

> -Original Message-
> From: Venkatesh Yadav Abbarapu 
> Sent: Tuesday, January 2, 2024 6:23 PM
> To: u-boot@lists.denx.de
> Cc: Simek, Michal ; ja...@amarulasolutions.com;
> g...@xilinx.com
> Subject: [PATCH] mtd: spi-nor: scale up timeout for full-chip erase
> 
> This patch fixes timeout issues seen on large NOR flash.
> For full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7) opcode.
> Use a different timeout for full-chip erase than for other commands.
> 
>  [Ported from Linux kernel commit
> 09b6a377687b ("mtd: spi-nor: scale up timeout for
>full-chip erase") ]
> 
> Signed-off-by: Venkatesh Yadav Abbarapu 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 9a1801ba93..171c68787c 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -45,6 +45,12 @@
> 
>  #define DEFAULT_READY_WAIT_JIFFIES   (40UL * HZ)
> 
> +/*
> + * For full-chip erase, calibrated to a 2MB flash (M25P16); should be
> +scaled up
> + * for larger flash
> + */
> +#define CHIP_ERASE_2MB_READY_WAIT_JIFFIES  (40UL * HZ)
> +
>  #define ROUND_UP_TO(x, y)(((x) + (y) - 1) / (y) * (y))
> 
>  struct sfdp_parameter_header {
> @@ -832,6 +838,20 @@ static int spi_nor_wait_till_ready(struct spi_nor
> *nor)
> 
> DEFAULT_READY_WAIT_JIFFIES);
>  }
> 
> +static int spi_nor_erase_chip_wait_till_ready(struct spi_nor *nor,
> +unsigned long size) {
> + /*
> +  * Scale the timeout linearly with the size of the flash, with
> +  * a minimum calibrated to an old 2MB flash. We could try to
> +  * pull these from CFI/SFDP, but these values should be good
> +  * enough for now.
> +  */
> + unsigned long timeout =
> max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
> + CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
> + (unsigned long)(size / SZ_2M));
> + return spi_nor_wait_till_ready_with_timeout(nor, timeout); }
> +
>  #ifdef CONFIG_SPI_FLASH_BAR
>  /*
>   * This "clean_bar" is necessary in a situation when one was accessing @@ -
> 966,7 +986,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
> erase_info *instr)  {
>   struct spi_nor *nor = mtd_to_spi_nor(mtd);
>   bool addr_known = false;
> - u32 addr, len, rem;
> + u32 addr, len, rem, max_size;
>   int ret, err;
> 
>   dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr, @@
> -980,6 +1000,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
> erase_info *instr)
> 
>   addr = instr->addr;
>   len = instr->len;
> + max_size = instr->len;
> 
>   instr->state = MTD_ERASING;
>   addr_known = true;
> @@ -1012,7 +1033,13 @@ static int spi_nor_erase(struct mtd_info *mtd,
> struct erase_info *instr)
>   addr += ret;
>   len -= ret;
> 
> - ret = spi_nor_wait_till_ready(nor);
> + if (max_size == mtd->size &&
> + !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
> + ret = spi_nor_erase_chip_wait_till_ready(nor, mtd-
> >size);
> + } else {
> + ret = spi_nor_wait_till_ready(nor);
> + }
> +
>   if (ret)
>   goto erase_err;
>   }
> --
> 2.25.1



RE: [PATCH] mmc: Change the frequency to MMC_HS_52 when selecting hs400

2024-05-06 Thread Abbarapu, Venkatesh
Do you have any comments for this patch?

Thanks
Venkatesh

> -Original Message-
> From: Venkatesh Yadav Abbarapu 
> Sent: Tuesday, April 23, 2024 11:01 AM
> To: u-boot@lists.denx.de
> Cc: peng@nxp.com; jh80.ch...@samsung.com; git (AMD-Xilinx)
> 
> Subject: [PATCH] mmc: Change the frequency to MMC_HS_52 when selecting
> hs400
> 
> Per JESD84-B51 P47, host need to change frequency to <=52MHz after setting
> HS_TIMING to 0x1, and host need to set the 8-bit DDR buswidth. Currently
> setting the frequency to 26MHz and trying to switch 8-bit DDR buswidth
> resulting timeouts.
> 
> mmc dev 1 0
> Select HS400 failed -110
> switch to partitions #0, OK
> mmc1(part 0) is current device
> 
> Signed-off-by: Venkatesh Yadav Abbarapu 
> ---
>  drivers/mmc/mmc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> 7b068c71ff..a2ed99aefe 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -962,8 +962,8 @@ static int mmc_set_card_speed(struct mmc *mmc,
> enum bus_mode mode,
>* Extended CSD. Reconfigure the controller to run at HS mode.
>*/
>   if (hsdowngrade) {
> - mmc_select_mode(mmc, MMC_HS);
> - mmc_set_clock(mmc, mmc_mode2freq(mmc, MMC_HS),
> false);
> + mmc_select_mode(mmc, MMC_HS_52);
> + mmc_set_clock(mmc, mmc_mode2freq(mmc, MMC_HS_52),
> false);
>   }
>  #endif
> 
> @@ -2043,7 +2043,7 @@ static int mmc_select_hs400(struct mmc *mmc)
>   }
> 
>   /* Set back to HS */
> - mmc_set_card_speed(mmc, MMC_HS, true);
> + mmc_set_card_speed(mmc, MMC_HS_52, true);
> 
>   err = mmc_hs400_prepare_ddr(mmc);
>   if (err)
> --
> 2.17.1



RE: [PATCH v11 0/8] spi-nor: Add parallel and stacked memories support

2024-05-06 Thread Abbarapu, Venkatesh
+ Tom Rini

Do you have any comments for this series?

Thanks
Venkatesh

> -Original Message-
> From: Venkatesh Yadav Abbarapu 
> Sent: Monday, March 4, 2024 8:41 AM
> To: u-boot@lists.denx.de
> Cc: Simek, Michal ; ja...@amarulasolutions.com;
> git (AMD-Xilinx) 
> Subject: [PATCH v11 0/8] spi-nor: Add parallel and stacked memories support
> 
> This series adds support for Xilinx qspi parallel and stacked memeories.
> 
> In parallel mode, the current implementation assumes that a maximum of
> two flashes are connected. The QSPI controller splits the data evenly between
> both the flashes so, both the flashes that are connected in parallel mode
> should be identical.
> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
> nor->flags.
> 
> In stacked mode the current implementation assumes that a maximum of two
> flashes are connected and both the flashes are of same make but can differ in
> sizes. So, except the sizes all other flash parameters of both the flashes are
> identical.
> 
> Spi-nor will pass on the appropriate flash select flag to low level driver, 
> and it
> will select pass all the data to that particular flash.
> 
> Write operation in parallel mode are performed in page size * 2 chunks as
> each write operation results in writing both the flashes. For doubling the
> address space each operation is performed at addr/2 flash offset, where addr
> is the address specified by the user.
> 
> Similarly for read and erase operations it will read from both flashes, so 
> size
> and offset are divided by 2 and send to flash.
> 
> Changes in v2:
> - Fixed the compilation issues.
> Changes in v3:
> - Fixed the CI issues.
> Changes in v4:
> - Removed the dio,dummy_bytes variables from zynq_qspi driver.
> - Fix the compilation issue by including the DM_SPI config.
> Changes in v5:
> - Fixed the issue reported by buildman.
> Changes in v6:
> - Fixed the issues reported while running the sandbox test cases.
> Changes in v7:
> - Fixed the issues reported while running these da850evm_defconfig,
>   imx28_xea_defconfig configs.
> - Fixed the issue when DM_SPI config is disabled.
> - Fixed the issue while running the sandbox_noinst_defconfig with spl
>   ./spl/u-boot-spl -d arch/sandbox/dts/test.dtb
>jedec_spi_nor spi.bin@0: has no valid 'reg' property (-12)
>jedec_spi_nor spi.bin@1: has no valid 'reg' property (-12)
>### ERROR ### Please RESET the board ### Changes in v8:
> - Fixed the compilation issue with imx28_xea_defconfig.
> - Fixed the SPL size issue with the axm and taurus defconfigs.
> - Rebased the patches on top of next branch.
> Changes in v9:
> - Updated the commit log why SPL_FIT is being enabled.
> Changes in v10:
> - Added the new config SPI_ADVANCE to fix the issue while enabling
> imx28_xea_defconfig.
> Changes in v11:
> - Removed the unused variable, corrected the type of variable and replaced
> memcpy with memmove.
> 
> Ashok Reddy Soma (4):
>   mtd: spi-nor: Add parallel and stacked memories support
>   mtd: spi-nor: Add parallel memories support for read_sr and read_fsr
>   mtd: spi-nor: Add parallel and stacked memories support in read_bar
> and write_bar
>   spi: spi-uclass: Read chipselect and restrict capabilities
> 
> Venkatesh Yadav Abbarapu (4):
>   spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver
>   spi: zynq_qspi: Add parallel memories support in QSPI driver
>   spi: Add the spi advance options for non SPL
>   config: xea: Enable the SPI_ADVANCE config option
> 
>  configs/imx28_xea_defconfig|   1 +
>  drivers/mtd/spi/sandbox.c  |   2 +-
>  drivers/mtd/spi/spi-nor-core.c | 399 -
>  drivers/spi/Kconfig|   7 +
>  drivers/spi/altera_spi.c   |   4 +-
>  drivers/spi/atcspi200_spi.c|   2 +-
>  drivers/spi/ath79_spi.c|   2 +-
>  drivers/spi/atmel_spi.c|   6 +-
>  drivers/spi/bcm63xx_hsspi.c|  42 ++--
>  drivers/spi/bcm63xx_spi.c  |   6 +-
>  drivers/spi/bcmbca_hsspi.c |  34 +--
>  drivers/spi/cf_spi.c   |   6 +-
>  drivers/spi/davinci_spi.c  |   8 +-
>  drivers/spi/fsl_dspi.c |  18 +-
>  drivers/spi/fsl_espi.c |   4 +-
>  drivers/spi/fsl_qspi.c |   4 +-
>  drivers/spi/gxp_spi.c  |   2 +-
>  drivers/spi/mpc8xx_spi.c   |   4 +-
>  drivers/spi/mpc8xxx_spi.c  |  10 +-
>  drivers/spi/mscc_bb_spi.c  |   4 +-
>  drivers/spi/mxc_spi.c  |   6 +-
>  drivers/spi/npcm_fiu_spi.c |  14 +-
>  drivers/spi/nxp_fspi.c |   2 +-
>  drivers/spi/octeon_spi.c   |   2 +-
>  drivers/spi/omap3_spi.c|   4 +-
>  drivers/spi/pic32_spi.c|   2 +-
>  drivers/spi/rk_spi.c   |   4 +-
>  drivers/spi/rockchip_sfc.c |   2 +-
>  drivers/spi/spi-aspeed-smc.c   |  28 +--
>  drivers/spi/spi-mxic.c |   6 +-
>  drivers/spi/spi-qup.c  |   4 +-
>  drivers/spi/spi-sifive.c   |   6 +-
>  drivers/spi/spi-sn-f-ospi.c|   2 +-
>  drivers/spi/spi-sunxi.c

Re: [PATCH 13/16] rockchip: rk3588-rock-5b: Drop usb-typec node from u-boot.dtsi

2024-05-06 Thread Kever Yang



On 2024/5/5 03:43, Jonas Karlman wrote:

The usb-typec related nodes and props added in the board u-boot.dtsi
file has not yet landed in upstream Linux kernel DT, and they are not
needed for U-Boot to use the USB Type-C port in peripheral mode.

Remove superfluous usb-typec related nodes and props and replace them
with a simple dr_mode and maximum-speed prop to cleanup the board
u-boot.dtsi file.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 106 +---
  1 file changed, 2 insertions(+), 104 deletions(-)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index d6020ca790f6..69914f4ce183 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -4,32 +4,12 @@
   */
  
  #include "rk3588-u-boot.dtsi"

-#include 
-
-/ {
-   vcc12v_dcin: vcc12v-dcin-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc12v_dcin";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <1200>;
-   regulator-max-microvolt = <1200>;
-   };
-};
  
  _pins {

bootph-pre-ram;
bootph-some-ram;
  };
  
- {

-   usb {
-   usbc0_int: usbc0-int {
-   rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_none>;
-   };
-   };
-};
-
   {
cap-mmc-highspeed;
mmc-hs200-1_8v;
@@ -76,26 +56,7 @@
  };
  
  _phy0 {

-   orientation-switch;
-   mode-switch;
-   sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
-   sbu2-dc-gpios = < RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
-   port {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   usbdp_phy0_typec_ss: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_ss>;
-   };
-
-   usbdp_phy0_typec_sbu: endpoint@1 {
-   reg = <1>;
-   remote-endpoint = <_sbu>;
-   };
-   };
  };
  
  _phy0_u3 {

@@ -103,74 +64,11 @@
  };
  
  _host0_xhci {

-   usb-role-switch;
+   dr_mode = "peripheral";
+   maximum-speed = "high-speed";
status = "okay";
-
-   port {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   usb_host0_xhci_drd_sw: endpoint {
-   remote-endpoint = <_hs>;
-   };
-   };
  };
  
  _host1_xhci {

status = "okay";
  };
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer>;
-   status = "okay";
-
-   usbc0: usb-typec@22 {
-   compatible = "fcs,fusb302";
-   reg = <0x22>;
-   interrupt-parent = <>;
-   interrupts = ;
-   pinctrl-names = "default";
-   pinctrl-0 = <_int>;
-   vbus-supply = <_dcin>;
-   status = "okay";
-
-   usb_con: connector {
-   compatible = "usb-c-connector";
-   label = "USB-C";
-   data-role = "dual";
-   power-role = "sink";
-   try-power-role = "sink";
-   op-sink-microwatt = <100>;
-   sink-pdos =
-   ,
-   ;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@0 {
-   reg = <0>;
-   usbc0_hs: endpoint {
-   remote-endpoint = 
<_host0_xhci_drd_sw>;
-   };
-   };
-
-   port@1 {
-   reg = <1>;
-   usbc0_ss: endpoint {
-   remote-endpoint = 
<_phy0_typec_ss>;
-   };
-   };
-
-   port@2 {
-   reg = <2>;
-   usbc0_sbu: endpoint {
-   remote-endpoint = 
<_phy0_typec_sbu>;
-   };
-   };
-   };
-   };
-   };
-};


Re: [PATCH 12/16] phy: rockchip: usbdp: Adopt driver to work with upstream DT

2024-05-06 Thread Kever Yang



On 2024/5/5 03:43, Jonas Karlman wrote:

The upstream DT binding added in linux-phy next commit a75d8056e9fe
("dt-bindings: phy: add rockchip usbdp combo phy document") does not
define subnodes for the type of PHY, instead it is expected that phandle
args are used for setting the type of the PHY.

   phys = <_phy0 PHY_TYPE_USB3>

Adopt the usbdp phy driver to work with upstream DT binding targeted for
Linux kernel v6.10.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/phy/rockchip/phy-rockchip-usbdp.c | 63 ++-
  1 file changed, 17 insertions(+), 46 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c 
b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index bf0fb6d8288f..18e76402799b 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -21,7 +21,7 @@
  #include 
  #include 
  #include 
-
+#include 
  #include 
  
  #define BIT_WRITEABLE_SHIFT	16

@@ -585,10 +585,21 @@ static int udphy_power_off(struct rockchip_udphy *udphy, 
u8 mode)
return 0;
  }
  
+static int rockchip_u3phy_of_xlate(struct phy *phy,

+  struct ofnode_phandle_args *args)
+{
+   if (args->args_count == 0)
+   return -EINVAL;
+
+   if (args->args[0] != PHY_TYPE_USB3)
+   return -EINVAL;
+
+   return 0;
+}
+
  static int rockchip_u3phy_init(struct phy *phy)
  {
-   struct udevice *parent = phy->dev->parent;
-   struct rockchip_udphy *udphy = dev_get_priv(parent);
+   struct rockchip_udphy *udphy = dev_get_priv(phy->dev);
  
  	/* DP only or high-speed, disable U3 port */

if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
@@ -601,8 +612,7 @@ static int rockchip_u3phy_init(struct phy *phy)
  
  static int rockchip_u3phy_exit(struct phy *phy)

  {
-   struct udevice *parent = phy->dev->parent;
-   struct rockchip_udphy *udphy = dev_get_priv(parent);
+   struct rockchip_udphy *udphy = dev_get_priv(phy->dev);
  
  	/* DP only or high-speed */

if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
@@ -612,6 +622,7 @@ static int rockchip_u3phy_exit(struct phy *phy)
  }
  
  static const struct phy_ops rockchip_u3phy_ops = {

+   .of_xlate   = rockchip_u3phy_of_xlate,
.init   = rockchip_u3phy_init,
.exit   = rockchip_u3phy_exit,
  };
@@ -671,40 +682,6 @@ static int rockchip_udphy_probe(struct udevice *dev)
return 0;
  }
  
-static int rockchip_udphy_bind(struct udevice *parent)

-{
-   struct udevice *child;
-   ofnode subnode;
-   const char *node_name;
-   int ret;
-
-   dev_for_each_subnode(subnode, parent) {
-   if (!ofnode_valid(subnode)) {
-   printf("%s: no subnode for %s", __func__, parent->name);
-   return -ENXIO;
-   }
-
-   node_name = ofnode_get_name(subnode);
-   debug("%s: subnode %s\n", __func__, node_name);
-
-   /* if there is no match, continue */
-   if (strcasecmp(node_name, "usb3-port"))
-   continue;
-
-   /* node name is usb3-port */
-   ret = device_bind_driver_to_node(parent,
-"rockchip_udphy_u3_port",
-node_name, subnode, );
-   if (ret) {
-   printf("%s: '%s' cannot bind its driver\n",
-  __func__, node_name);
-   return ret;
-   }
-   }
-
-   return 0;
-}
-
  static int rk3588_udphy_refclk_set(struct rockchip_udphy *udphy)
  {
/* configure phy reference clock */
@@ -869,17 +846,11 @@ static const struct udevice_id rockchip_udphy_dt_match[] 
= {
{ /* sentinel */ }
  };
  
-U_BOOT_DRIVER(rockchip_udphy_u3_port) = {

-   .name   = "rockchip_udphy_u3_port",
-   .id = UCLASS_PHY,
-   .ops= _u3phy_ops,
-};
-
  U_BOOT_DRIVER(rockchip_udphy) = {
.name   = "rockchip_udphy",
.id = UCLASS_PHY,
.of_match   = rockchip_udphy_dt_match,
.probe  = rockchip_udphy_probe,
-   .bind   = rockchip_udphy_bind,
+   .ops= _u3phy_ops,
.priv_auto  = sizeof(struct rockchip_udphy),
  };


Re: [PATCH 11/16] phy: rockchip: usbdp: Drop rockchip_u3phy_uboot_init()

2024-05-06 Thread Kever Yang



On 2024/5/5 03:43, Jonas Karlman wrote:

Remove the rockchip_u3phy_uboot_init() function, it has no caller and is
not needed with proper driver model use.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/phy/rockchip/phy-rockchip-usbdp.c | 24 ---
  1 file changed, 24 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c 
b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 8e5821069757..bf0fb6d8288f 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -616,30 +616,6 @@ static const struct phy_ops rockchip_u3phy_ops = {
.exit   = rockchip_u3phy_exit,
  };
  
-int rockchip_u3phy_uboot_init(void)

-{
-   struct udevice *udev;
-   struct rockchip_udphy *udphy;
-   int ret;
-
-   ret = uclass_get_device_by_driver(UCLASS_PHY,
- DM_DRIVER_GET(rockchip_udphy_u3_port),
- );
-   if (ret) {
-   pr_err("%s: get u3-port failed: %d\n", __func__, ret);
-   return ret;
-   }
-
-   /* DP only or high-speed, disable U3 port */
-   udphy = dev_get_priv(udev->parent);
-   if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
-   udphy_u3_port_disable(udphy, true);
-   return 0;
-   }
-
-   return udphy_power_on(udphy, UDPHY_MODE_USB);
-}
-
  static int rockchip_udphy_probe(struct udevice *dev)
  {
struct rockchip_udphy *udphy = dev_get_priv(dev);


Re: [PATCH 10/16] phy: rockchip: usbdp: Find phy-id from the io address

2024-05-06 Thread Kever Yang



On 2024/5/5 03:43, Jonas Karlman wrote:

The upstream Linux kernel driver find the phy-id from the io address.

Change to use a similar method as the U-Boot inno-usb2 phy driver and
the Linux kernel driver to set correct phy-id.

This is based on the linux-phy next commit 2f70bbddeb45 ("phy: rockchip:
add usbdp combo phy driver").

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/phy/rockchip/phy-rockchip-usbdp.c | 39 ---
  1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c 
b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index baf92529348c..8e5821069757 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -74,6 +74,8 @@ struct udphy_grf_cfg {
  struct rockchip_udphy;
  
  struct rockchip_udphy_cfg {

+   unsigned int num_phys;
+   unsigned int phy_ids[2];
/* resets to be requested */
const char * const *rst_list;
int num_rsts;
@@ -640,17 +642,25 @@ int rockchip_u3phy_uboot_init(void)
  
  static int rockchip_udphy_probe(struct udevice *dev)

  {
-   const struct device_node *np = ofnode_to_np(dev_ofnode(dev));
struct rockchip_udphy *udphy = dev_get_priv(dev);
const struct rockchip_udphy_cfg *phy_cfgs;
+   unsigned int reg;
int id, ret;
  
  	udphy->dev = dev;
  
-	id = of_alias_get_id(np, "usbdp");

-   if (id < 0)
-   id = 0;
-   udphy->id = id;
+   ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 0, );
+   if (ret) {
+   dev_err(dev, "failed to read reg[0] property\n");
+   return ret;
+   }
+   if (reg == 0 && dev_read_addr_cells(dev) == 2) {
+   ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 1, );
+   if (ret) {
+   dev_err(dev, "failed to read reg[1] property\n");
+   return ret;
+   }
+   }
  
  	phy_cfgs = (const struct rockchip_udphy_cfg *)dev_get_driver_data(dev);

if (!phy_cfgs) {
@@ -659,6 +669,20 @@ static int rockchip_udphy_probe(struct udevice *dev)
}
udphy->cfgs = phy_cfgs;
  
+	/* find the phy-id from the io address */

+   udphy->id = -ENODEV;
+   for (id = 0; id < udphy->cfgs->num_phys; id++) {
+   if (reg == udphy->cfgs->phy_ids[id]) {
+   udphy->id = id;
+   break;
+   }
+   }
+
+   if (udphy->id < 0) {
+   dev_err(dev, "no matching device found\n");
+   return -ENODEV;
+   }
+
ret = regmap_init_mem(dev_ofnode(dev), >pma_regmap);
if (ret)
return ret;
@@ -838,6 +862,11 @@ static const char * const rk3588_udphy_rst_l[] = {
  };
  
  static const struct rockchip_udphy_cfg rk3588_udphy_cfgs = {

+   .num_phys = 2,
+   .phy_ids = {
+   0xfed8,
+   0xfed9,
+   },
.num_rsts = ARRAY_SIZE(rk3588_udphy_rst_l),
.rst_list = rk3588_udphy_rst_l,
.grfcfg = {


Re: [PATCH 08/16] rockchip: rk356x: Migrate to OF_UPSTREAM

2024-05-06 Thread Kever Yang



On 2024/5/5 03:43, Jonas Karlman wrote:

Migrate RK356x boards that exists in Linux v6.8 to use OF_UPSTREAM.

Following targets is not migrated to use OF_UPSTREAM:
- anbernic-rgxx3-rk3566: Multi device target
- generic-rk3568: Generic target only meant for U-Boot use
- pinetab2-rk3566: Merged in v6.9-rc1

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/Makefile | 20 
  arch/arm/mach-rockchip/Kconfig|  1 +
  configs/anbernic-rgxx3-rk3566_defconfig   |  1 +
  configs/bpi-r2-pro-rk3568_defconfig   |  2 +-
  configs/evb-rk3568_defconfig  |  4 ++--
  configs/generic-rk3568_defconfig  |  1 +
  configs/lubancat-2-rk3568_defconfig   |  2 +-
  configs/nanopi-r5c-rk3568_defconfig   |  2 +-
  configs/nanopi-r5s-rk3568_defconfig   |  2 +-
  configs/odroid-m1-rk3568_defconfig|  2 +-
  configs/pinetab2-rk3566_defconfig |  1 +
  configs/quartz64-a-rk3566_defconfig   |  2 +-
  configs/quartz64-b-rk3566_defconfig   |  2 +-
  configs/radxa-cm3-io-rk3566_defconfig |  2 +-
  configs/radxa-e25-rk3568_defconfig|  2 +-
  configs/rock-3a-rk3568_defconfig  |  2 +-
  configs/soquartz-blade-rk3566_defconfig   |  2 +-
  configs/soquartz-cm4-rk3566_defconfig |  2 +-
  configs/soquartz-model-a-rk3566_defconfig |  2 +-
  19 files changed, 19 insertions(+), 35 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7a65d98635ae..1dfcc05a14be 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -98,26 +98,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-geekbox.dtb \
rk3368-px5-evb.dtb \
  
-dtb-$(CONFIG_ROCKCHIP_RK3568) += \

-   rk3566-anbernic-rgxx3.dtb \
-   rk3566-pinetab2-v0.1.dtb \
-   rk3566-pinetab2-v2.0.dtb \
-   rk3566-quartz64-a.dtb \
-   rk3566-quartz64-b.dtb \
-   rk3566-radxa-cm3-io.dtb \
-   rk3566-soquartz-blade.dtb \
-   rk3566-soquartz-cm4.dtb \
-   rk3566-soquartz-model-a.dtb \
-   rk3568-bpi-r2-pro.dtb \
-   rk3568-evb.dtb \
-   rk3568-generic.dtb \
-   rk3568-lubancat-2.dtb \
-   rk3568-nanopi-r5c.dtb \
-   rk3568-nanopi-r5s.dtb \
-   rk3568-odroid-m1.dtb \
-   rk3568-radxa-e25.dtb \
-   rk3568-rock-3a.dtb
-
  dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588s-coolpi-4b.dtb \
rk3588-coolpi-cm5-evb.dtb \
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index a2c81489452e..03f6bf43fdf4 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -322,6 +322,7 @@ config ROCKCHIP_RK3568
imply MISC_INIT_R
imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
imply OF_LIBFDT_OVERLAY
+   imply OF_UPSTREAM
imply PHY_GIGE if DWC_ETH_QOS_ROCKCHIP
imply RNG_ROCKCHIP
imply ROCKCHIP_COMMON_BOARD
diff --git a/configs/anbernic-rgxx3-rk3566_defconfig 
b/configs/anbernic-rgxx3-rk3566_defconfig
index fcade9172b71..a03509bf4671 100644
--- a/configs/anbernic-rgxx3-rk3566_defconfig
+++ b/configs/anbernic-rgxx3-rk3566_defconfig
@@ -38,6 +38,7 @@ CONFIG_CMD_MMC=y
  # CONFIG_SPL_DOS_PARTITION is not set
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_OF_LIVE=y
+# CONFIG_OF_UPSTREAM is not set
  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
  # CONFIG_NET is not set
diff --git a/configs/bpi-r2-pro-rk3568_defconfig 
b/configs/bpi-r2-pro-rk3568_defconfig
index a0caa367f9db..eccc15a0ae51 100644
--- a/configs/bpi-r2-pro-rk3568_defconfig
+++ b/configs/bpi-r2-pro-rk3568_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
  CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_DEFAULT_DEVICE_TREE="rk3568-bpi-r2-pro"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3568-bpi-r2-pro"
  CONFIG_ROCKCHIP_RK3568=y
  CONFIG_SPL_SERIAL=y
  CONFIG_DEBUG_UART_BASE=0xFE66
diff --git a/configs/evb-rk3568_defconfig b/configs/evb-rk3568_defconfig
index e71d6705568f..2076f55122be 100644
--- a/configs/evb-rk3568_defconfig
+++ b/configs/evb-rk3568_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
  CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3568-evb1-v10"
  CONFIG_ROCKCHIP_RK3568=y
  CONFIG_SPL_SERIAL=y
  CONFIG_DEBUG_UART_BASE=0xFE66
@@ -14,7 +14,7 @@ CONFIG_FIT_VERBOSE=y
  CONFIG_SPL_FIT_SIGNATURE=y
  CONFIG_SPL_LOAD_FIT=y
  CONFIG_LEGACY_IMAGE_FORMAT=y
-CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-evb.dtb"
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-evb1-v10.dtb"
  # CONFIG_DISPLAY_CPUINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x4
diff --git a/configs/generic-rk3568_defconfig b/configs/generic-rk3568_defconfig
index 033702fd149f..66a33afbbaf0 100644
--- a/configs/generic-rk3568_defconfig
+++ 

Re: [PATCH 07/16] rockchip: rk356x: Add rk3568-u-boot.dtsi

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

Add a -u-boot.dtsi file that gets included by default
for RK356x boards when a board specific u-boot.dtsi file dont exists.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3568-u-boot.dtsi | 3 +++
  1 file changed, 3 insertions(+)
  create mode 100644 arch/arm/dts/rk3568-u-boot.dtsi

diff --git a/arch/arm/dts/rk3568-u-boot.dtsi b/arch/arm/dts/rk3568-u-boot.dtsi
new file mode 100644
index ..6e8307e3bdf6
--- /dev/null
+++ b/arch/arm/dts/rk3568-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"


Re: [PATCH 05/16] rockchip: rk3399: Migrate to OF_UPSTREAM

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

All RK3399 boards has now been synced to Linux kernel v6.8 DTs and can
migrate to use OF_UPSTREAM.

Migrate RK3399 boards that exists in Linux v6.8 to use OF_UPSTREAM.

Following target is not migrated to use OF_UPSTREAM:
- nanopi-m4-2gb-rk3399: DDR3 variant of nanopi-m4-rk3399 (LPDDR3)

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/Makefile| 31 
  arch/arm/mach-rockchip/Kconfig   |  1 +
  configs/chromebook_bob_defconfig |  2 +-
  configs/chromebook_kevin_defconfig   |  2 +-
  configs/eaidk-610-rk3399_defconfig   |  2 +-
  configs/evb-rk3399_defconfig |  2 +-
  configs/ficus-rk3399_defconfig   |  2 +-
  configs/firefly-rk3399_defconfig |  2 +-
  configs/khadas-edge-captain-rk3399_defconfig |  2 +-
  configs/khadas-edge-rk3399_defconfig |  2 +-
  configs/khadas-edge-v-rk3399_defconfig   |  2 +-
  configs/leez-rk3399_defconfig|  2 +-
  configs/nanopc-t4-rk3399_defconfig   |  2 +-
  configs/nanopi-m4-2gb-rk3399_defconfig   |  1 +
  configs/nanopi-m4-rk3399_defconfig   |  2 +-
  configs/nanopi-m4b-rk3399_defconfig  |  2 +-
  configs/nanopi-neo4-rk3399_defconfig |  2 +-
  configs/nanopi-r4s-rk3399_defconfig  |  2 +-
  configs/orangepi-rk3399_defconfig|  2 +-
  configs/pinebook-pro-rk3399_defconfig|  2 +-
  configs/pinephone-pro-rk3399_defconfig   |  2 +-
  configs/puma-rk3399_defconfig|  2 +-
  configs/roc-pc-mezzanine-rk3399_defconfig|  2 +-
  configs/roc-pc-rk3399_defconfig  |  2 +-
  configs/rock-4c-plus-rk3399_defconfig|  2 +-
  configs/rock-4se-rk3399_defconfig|  2 +-
  configs/rock-pi-4-rk3399_defconfig   |  2 +-
  configs/rock-pi-4c-rk3399_defconfig  |  2 +-
  configs/rock-pi-n10-rk3399pro_defconfig  |  2 +-
  configs/rock960-rk3399_defconfig |  2 +-
  configs/rockpro64-rk3399_defconfig   |  2 +-
  31 files changed, 30 insertions(+), 59 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b7ada58695be..7a65d98635ae 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -98,37 +98,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-geekbox.dtb \
rk3368-px5-evb.dtb \
  
-dtb-$(CONFIG_ROCKCHIP_RK3399) += \

-   rk3399-evb.dtb \
-   rk3399-eaidk-610.dtb \
-   rk3399-ficus.dtb \
-   rk3399-firefly.dtb \
-   rk3399-gru-bob.dtb \
-   rk3399-gru-kevin.dtb \
-   rk3399-khadas-edge.dtb \
-   rk3399-khadas-edge-captain.dtb \
-   rk3399-khadas-edge-v.dtb \
-   rk3399-leez-p710.dtb \
-   rk3399-nanopc-t4.dtb \
-   rk3399-nanopi-m4.dtb \
-   rk3399-nanopi-m4-2gb.dtb \
-   rk3399-nanopi-m4b.dtb \
-   rk3399-nanopi-neo4.dtb \
-   rk3399-nanopi-r4s.dtb \
-   rk3399-orangepi.dtb \
-   rk3399-pinebook-pro.dtb \
-   rk3399-pinephone-pro.dtb \
-   rk3399-puma-haikou.dtb \
-   rk3399-roc-pc.dtb \
-   rk3399-roc-pc-mezzanine.dtb \
-   rk3399-rock-4c-plus.dtb \
-   rk3399-rock-4se.dtb \
-   rk3399-rock-pi-4a.dtb \
-   rk3399-rock-pi-4c.dtb \
-   rk3399-rock960.dtb \
-   rk3399-rockpro64.dtb \
-   rk3399pro-rock-pi-n10.dtb
-
  dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-pinetab2-v0.1.dtb \
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index a492b0885c03..a2c81489452e 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -272,6 +272,7 @@ config ROCKCHIP_RK3399
imply MISC_INIT_R
imply OF_LIBFDT_OVERLAY
imply OF_LIVE
+   imply OF_UPSTREAM
imply PARTITION_TYPE_GUID
imply PHY_GIGE if GMAC_ROCKCHIP
imply PRE_CONSOLE_BUFFER
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index 9e15d9e3b8f6..acfe3934104f 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -9,7 +9,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-bob"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-gru-bob"
  CONFIG_SPL_TEXT_BASE=0xff8c2000
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3399=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index a79703c0a138..95fdb418d82b 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -9,7 +9,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-kevin"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-gru-kevin"
  

Re: [PATCH 03/16] rockchip: rk3328: Migrate to OF_UPSTREAM

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

All RK3328 boards has now been synced to Linux kernel v6.8 DTs and can
migrate to use OF_UPSTREAM.

Migrate all RK3328 boards to use OF_UPSTREAM.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/Makefile | 11 ---
  arch/arm/mach-rockchip/Kconfig|  1 +
  configs/evb-rk3328_defconfig  |  2 +-
  configs/nanopi-r2c-plus-rk3328_defconfig  |  2 +-
  configs/nanopi-r2c-rk3328_defconfig   |  2 +-
  configs/nanopi-r2s-rk3328_defconfig   |  2 +-
  configs/orangepi-r1-plus-lts-rk3328_defconfig |  2 +-
  configs/orangepi-r1-plus-rk3328_defconfig |  2 +-
  configs/roc-cc-rk3328_defconfig   |  2 +-
  configs/rock-pi-e-rk3328_defconfig|  2 +-
  configs/rock64-rk3328_defconfig   |  2 +-
  11 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 319ec23a4fee..b7ada58695be 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,17 +92,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb
  
-dtb-$(CONFIG_ROCKCHIP_RK3328) += \

-   rk3328-evb.dtb \
-   rk3328-nanopi-r2c.dtb \
-   rk3328-nanopi-r2c-plus.dtb \
-   rk3328-nanopi-r2s.dtb \
-   rk3328-orangepi-r1-plus.dtb \
-   rk3328-orangepi-r1-plus-lts.dtb \
-   rk3328-roc-cc.dtb \
-   rk3328-rock64.dtb \
-   rk3328-rock-pi-e.dtb
-
  dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-lion-haikou.dtb \
rk3368-sheep.dtb \
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index f1caf4f3738b..a492b0885c03 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -197,6 +197,7 @@ config ROCKCHIP_RK3328
imply MISC
imply MISC_INIT_R
imply OF_LIVE
+   imply OF_UPSTREAM
imply PRE_CONSOLE_BUFFER
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_EFUSE
diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 53ad6777ec50..bfb85223437d 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -5,7 +5,7 @@ CONFIG_ARCH_ROCKCHIP=y
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3328-evb"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3328-evb"
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3328=y
  CONFIG_DEBUG_UART_BASE=0xFF13
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index beef682a582e..f311a0a80ba7 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -6,7 +6,7 @@ CONFIG_SPL_GPIO=y
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3328-nanopi-r2c-plus"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3328-nanopi-r2c-plus"
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3328=y
  CONFIG_DEBUG_UART_BASE=0xFF13
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 8960c1afaba5..533dc1029f73 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -6,7 +6,7 @@ CONFIG_SPL_GPIO=y
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3328-nanopi-r2c"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3328-nanopi-r2c"
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3328=y
  CONFIG_DEBUG_UART_BASE=0xFF13
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 96e67e248d32..2591a9cc8ab2 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -6,7 +6,7 @@ CONFIG_SPL_GPIO=y
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3328-nanopi-r2s"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3328-nanopi-r2s"
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3328=y
  CONFIG_DEBUG_UART_BASE=0xFF13
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 5fbbd5fc6558..14cdbd813c81 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -6,7 +6,7 @@ CONFIG_SPL_GPIO=y
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_DEFAULT_DEVICE_TREE="rk3328-orangepi-r1-plus-lts"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3328-orangepi-r1-plus-lts"
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3328=y
  CONFIG_ROCKCHIP_SPI_IMAGE=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index c5afe5ea6e5c..7fe58e7a1467 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -6,7 +6,7 @@ 

Re: [PATCH 02/16] rockchip: rk3308: Remove redundant device tree files

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

Remove redundant device tree files now that RK3308 boards have been
migrated to use OF_UPSTREAM.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3308-evb.dts|  230 ---
  arch/arm/dts/rk3308-roc-cc.dts |  190 ---
  arch/arm/dts/rk3308-rock-pi-s.dts  |  314 
  arch/arm/dts/rk3308.dtsi   | 1888 
  include/dt-bindings/clock/rk3308-cru.h |  387 -
  5 files changed, 3009 deletions(-)
  delete mode 100644 arch/arm/dts/rk3308-evb.dts
  delete mode 100644 arch/arm/dts/rk3308-roc-cc.dts
  delete mode 100644 arch/arm/dts/rk3308-rock-pi-s.dts
  delete mode 100644 arch/arm/dts/rk3308.dtsi
  delete mode 100644 include/dt-bindings/clock/rk3308-cru.h

diff --git a/arch/arm/dts/rk3308-evb.dts b/arch/arm/dts/rk3308-evb.dts
deleted file mode 100644
index 184b84fdde07..
--- a/arch/arm/dts/rk3308-evb.dts
+++ /dev/null
@@ -1,230 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
- *
- */
-
-/dts-v1/;
-#include 
-#include "rk3308.dtsi"
-
-/ {
-   model = "Rockchip RK3308 EVB";
-   compatible = "rockchip,rk3308-evb", "rockchip,rk3308";
-
-   chosen {
-   stdout-path = "serial4:150n8";
-   };
-
-   adc-keys0 {
-   compatible = "adc-keys";
-   io-channels = < 0>;
-   io-channel-names = "buttons";
-   poll-interval = <100>;
-   keyup-threshold-microvolt = <180>;
-
-   button-func {
-   linux,code = ;
-   label = "function";
-   press-threshold-microvolt = <18000>;
-   };
-   };
-
-   adc-keys1 {
-   compatible = "adc-keys";
-   io-channels = < 1>;
-   io-channel-names = "buttons";
-   poll-interval = <100>;
-   keyup-threshold-microvolt = <180>;
-
-   button-esc {
-   linux,code = ;
-   label = "micmute";
-   press-threshold-microvolt = <113>;
-   };
-
-   button-home {
-   linux,code = ;
-   label = "mode";
-   press-threshold-microvolt = <901000>;
-   };
-
-   button-menu {
-   linux,code = ;
-   label = "play";
-   press-threshold-microvolt = <624000>;
-   };
-
-   button-down {
-   linux,code = ;
-   label = "volume down";
-   press-threshold-microvolt = <30>;
-   };
-
-   button-up {
-   linux,code = ;
-   label = "volume up";
-   press-threshold-microvolt = <18000>;
-   };
-   };
-
-   gpio-keys {
-   compatible = "gpio-keys";
-   autorepeat;
-
-   pinctrl-names = "default";
-   pinctrl-0 = <_key>;
-
-   key-power {
-   gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   label = "GPIO Key Power";
-   debounce-interval = <100>;
-   wakeup-source;
-   };
-   };
-
-   vcc12v_dcin: vcc12v-dcin {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc12v_dcin";
-   regulator-min-microvolt = <1200>;
-   regulator-max-microvolt = <1200>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-
-   vcc5v0_sys: vcc5v0-sys {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc5v0_sys";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   regulator-boot-on;
-   vin-supply = <_dcin>;
-   };
-
-   vccio_sdio: vcc_1v8: vcc-1v8 {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_1v8";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   regulator-always-on;
-   regulator-boot-on;
-   vin-supply = <_io>;
-   };
-
-   vcc_ddr: vcc-ddr {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_ddr";
-   regulator-min-microvolt = <150>;
-   regulator-max-microvolt = <150>;
-   regulator-always-on;
-   regulator-boot-on;
-   vin-supply = <_sys>;
-   };
-
-   vcc_io: vcc-io {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_io";

Re: [PATCH 01/16] rockchip: rk3308: Migrate to OF_UPSTREAM

2024-05-06 Thread Kever Yang



On 2024/5/5 03:42, Jonas Karlman wrote:

All RK3308 boards has now been synced to Linux kernel v6.8 DTs and can
migrate to use OF_UPSTREAM.

Migrate all RK3308 boards to use OF_UPSTREAM.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/Makefile  | 5 -
  arch/arm/mach-rockchip/Kconfig | 1 +
  configs/evb-rk3308_defconfig   | 2 +-
  configs/roc-cc-rk3308_defconfig| 2 +-
  configs/rock-pi-s-rk3308_defconfig | 2 +-
  5 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c9f1b25ad647..319ec23a4fee 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,11 +92,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb
  
-dtb-$(CONFIG_ROCKCHIP_RK3308) += \

-   rk3308-evb.dtb \
-   rk3308-roc-cc.dtb \
-   rk3308-rock-pi-s.dtb
-
  dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-nanopi-r2c.dtb \
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 262cb7cba3ea..f1caf4f3738b 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -166,6 +166,7 @@ config ROCKCHIP_RK3308
imply LEGACY_IMAGE_FORMAT
imply MISC
imply MISC_INIT_R
+   imply OF_UPSTREAM
imply RNG_ROCKCHIP
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_OTP
diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig
index 04a94e13a68a..f4c2ea12adaa 100644
--- a/configs/evb-rk3308_defconfig
+++ b/configs/evb-rk3308_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
  CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_DEFAULT_DEVICE_TREE="rk3308-evb"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-evb"
  CONFIG_OF_LIBFDT_OVERLAY=y
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3308=y
diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig
index ef58bd657532..862ea4301f25 100644
--- a/configs/roc-cc-rk3308_defconfig
+++ b/configs/roc-cc-rk3308_defconfig
@@ -3,7 +3,7 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
  CONFIG_SPL_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="rk3308-roc-cc"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-roc-cc"
  CONFIG_OF_LIBFDT_OVERLAY=y
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3308=y
diff --git a/configs/rock-pi-s-rk3308_defconfig 
b/configs/rock-pi-s-rk3308_defconfig
index 37a124eae181..c15ba3d8a451 100644
--- a/configs/rock-pi-s-rk3308_defconfig
+++ b/configs/rock-pi-s-rk3308_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
  CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_DEFAULT_DEVICE_TREE="rk3308-rock-pi-s"
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-rock-pi-s"
  CONFIG_OF_LIBFDT_OVERLAY=y
  CONFIG_DM_RESET=y
  CONFIG_ROCKCHIP_RK3308=y


Re: [PATCH v3] configs: rk3588-turing-rk1: disable SPI flash by default

2024-05-06 Thread Kever Yang



On 2024/5/3 04:07, Sam Edwards wrote:

While the Turing RK1 board has a pad on the PCB for SPI flash, it is
not populated at the factory: supporting SPI flash boot is a user
modification, not an out-of-the-box feature. The defconfig for this
board should therefore not be enabling the SPI flash image nor SPI
support in the SPL, as it causes confusion among downstream users as to
whether the SPI image needs to be distributed.

Fixes: 153ac950a599 ("board: rockchip: Add the Turing RK1 SoM")
Suggested-by: Florian Klink 
Signed-off-by: Sam Edwards 
Acked-by: Joshua Riek 
Reviewed-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changes v1->v2 (both requested by Jonas):
- Added back (i.e. made unremoved by patch) CONFIG_USB_GADGET_PRODUCT_NUM value
   previously automatically removed by savedefconfig.
- Also disable SPI/SFC driver entirely until SPI/SFC lands in the DT (if ever).

Changes v2->v3:
- Rebased onto latest master for clean apply

---
  configs/turing-rk1-rk3588_defconfig | 14 +-
  1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/configs/turing-rk1-rk3588_defconfig 
b/configs/turing-rk1-rk3588_defconfig
index 038b14769e..39ef05477a 100644
--- a/configs/turing-rk1-rk3588_defconfig
+++ b/configs/turing-rk1-rk3588_defconfig
@@ -3,17 +3,12 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_SYS_HAS_NONCACHED_MEMORY=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_SF_DEFAULT_SPEED=2400
-CONFIG_SF_DEFAULT_MODE=0x2000
  CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
  CONFIG_ROCKCHIP_RK3588=y
-CONFIG_ROCKCHIP_SPI_IMAGE=y
  CONFIG_SPL_SERIAL=y
  CONFIG_TARGET_TURINGRK1_RK3588=y
  CONFIG_DEBUG_UART_BASE=0xFEBC
  CONFIG_DEBUG_UART_CLOCK=2400
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
  CONFIG_SYS_LOAD_ADDR=0xc00800
  CONFIG_PCI=y
  CONFIG_DEBUG_UART=y
@@ -29,8 +24,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x4
  CONFIG_SPL_PAD_TO=0x7f8000
  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
  CONFIG_SPL_ATF=y
  CONFIG_CMD_GPIO=y
  CONFIG_CMD_GPT=y
@@ -64,11 +57,7 @@ CONFIG_MMC_DW_ROCKCHIP=y
  CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_SDMA=y
  CONFIG_MMC_SDHCI_ROCKCHIP=y
-CONFIG_SF_DEFAULT_BUS=5
-CONFIG_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPI_FLASH_MACRONIX=y
-CONFIG_SPI_FLASH_XMC=y
-CONFIG_SPI_FLASH_XTX=y
+# CONFIG_SPI_FLASH is not set
  CONFIG_PHY_REALTEK=y
  CONFIG_DWC_ETH_QOS=y
  CONFIG_DWC_ETH_QOS_ROCKCHIP=y
@@ -84,7 +73,6 @@ CONFIG_SPL_RAM=y
  CONFIG_SCSI=y
  CONFIG_DEBUG_UART_SHIFT=2
  CONFIG_SYS_NS16550_MEM32=y
-CONFIG_ROCKCHIP_SFC=y
  CONFIG_SYSRESET=y
  CONFIG_USB=y
  CONFIG_USB_XHCI_HCD=y


Re: [PATCH] clk: rockchip: rk3328: Add SCLK_USB3OTG_REF support

2024-05-06 Thread Kever Yang



On 2024/5/2 03:23, Jonas Karlman wrote:

The SCLK_USB3OTG_REF clocks is used as reference clock for USB3 block.

Add simple support to get rate of SCLK_USB3OTG_REF clocks to fix
reference clock period configuration.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
This has been runtime tested on a Rock64 and NanoPi R2S Plus.
---
  drivers/clk/rockchip/clk_rk3328.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3328.c 
b/drivers/clk/rockchip/clk_rk3328.c
index 87075ec71340..314b903eaa03 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -706,6 +706,9 @@ static ulong rk3328_clk_get_rate(struct clk *clk)
case PCLK_HDMIPHY:
rate = rk3328_hdmiphy_get_clk(priv->cru);
break;
+   case SCLK_USB3OTG_REF:
+   rate = OSC_HZ;
+   break;
default:
return -ENOENT;
}
@@ -780,6 +783,7 @@ static ulong rk3328_clk_set_rate(struct clk *clk, ulong 
rate)
case PCLK_DDR:
case ACLK_GMAC:
case PCLK_GMAC:
+   case SCLK_USB3OTG_REF:
case SCLK_USB3OTG_SUSPEND:
case USB480M:
return 0;


Re: [PATCH] rockchip: rk3328: Add missing bootph-some-ram props

2024-05-06 Thread Kever Yang



On 2024/5/2 03:21, Jonas Karlman wrote:

Add bootph-some-ram props to pinctrl nodes related to eMMC, SD-card and
SPI flash to match e.g. RK3308 and RK3399.

Also adjust bootph props for sdio_vcc_pin, pinctrl and uart2m1_xfer.

Fixes: 1e21f5693045 ("rockchip: rk3328: Fix loading FIT from SD-card when booting 
from eMMC")
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
This has been runtime tested on a Rock64 and NanoPi R2S Plus.

The uart2m1_xfer change help speed up boot by around 100 ms.
---
  arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi|  2 +-
  .../rk3328-orangepi-r1-plus-lts-u-boot.dtsi   |  7 ---
  .../dts/rk3328-orangepi-r1-plus-u-boot.dtsi   |  7 ---
  arch/arm/dts/rk3328-rock64-u-boot.dtsi|  7 ---
  arch/arm/dts/rk3328-u-boot.dtsi   | 20 +++
  5 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi 
b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
index 4fa170eeaf8d..d8c79600b659 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -12,7 +12,7 @@
  };
  
  _vcc_pin {

-   bootph-all;
+   bootph-pre-ram;
  };
  
  _otg {

diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi 
b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
index 0a9423cd9c7e..b50c1332b836 100644
--- a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
@@ -8,9 +8,6 @@
  #include "rk3328-sdram-lpddr3-666.dtsi"
  
   {

-   bootph-pre-ram;
-   bootph-some-ram;
-
flash@0 {
bootph-pre-ram;
bootph-some-ram;
@@ -19,18 +16,22 @@
  
  _clk {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _cs0 {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _rx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _tx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _otg {

diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi 
b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
index 1096821fc5d3..8ae003bbefd1 100644
--- a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
@@ -8,9 +8,6 @@
  #include "rk3328-sdram-ddr4-666.dtsi"
  
   {

-   bootph-pre-ram;
-   bootph-some-ram;
-
flash@0 {
bootph-pre-ram;
bootph-some-ram;
@@ -19,18 +16,22 @@
  
  _clk {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _cs0 {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _rx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _tx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _otg {

diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 551cff6f24f6..22f128090f84 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -30,9 +30,6 @@
  };
  
   {

-   bootph-pre-ram;
-   bootph-some-ram;
-
flash@0 {
bootph-pre-ram;
bootph-some-ram;
@@ -41,18 +38,22 @@
  
  _clk {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _cs0 {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _rx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _tx {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _otg {

diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index d3608bd0e2b2..0135bc08d491 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -17,7 +17,6 @@
};
  
  	dmc: dmc {

-   bootph-all;
compatible = "rockchip,rk3328-dmc";
reg = <0x0 0xff40 0x0 0x1000
   0x0 0xff78 0x0 0x3000
@@ -25,6 +24,7 @@
   0x0 0xff44 0x0 0x1000
   0x0 0xff72 0x0 0x1000
   0x0 0xff798000 0x0 0x1000>;
+   bootph-all;
};
  };
  
@@ -42,14 +42,17 @@
  
  _bus8 {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _clk {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _cmd {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
   {

@@ -66,10 +69,12 @@
  
  _pull_none_8ma {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _pull_none_12ma {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _pull_up {

@@ -78,19 +83,21 @@
  
  _pull_up_4ma {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _pull_up_8ma {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _pull_up_12ma {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
   {

-   bootph-pre-ram;
-   bootph-some-ram;
+   bootph-all;
  };
  
   {

@@ -103,18 +110,22 @@
  
  _bus4 {

bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _clk {

bootph-pre-ram;
+  

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

2024-05-06 Thread Minda Chen


> 
> On 30.04.24 11:59, E Shattow wrote:
> > On Tue, Apr 30, 2024 at 12:18 AM Heinrich Schuchardt
> >  wrote:
> >>
> >> On 30.04.24 00:46, E Shattow wrote:
> >>> On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing
> >>>  wrote:
> 
>  Heinrich Schuchardt wrote:
> > We already support the VisionFive 2 and the Milk-V Mars board by
> > patching the VisionFive 2 device tree. With this patch the same is
> > done for the Milk-V Mars CM.
> 
>  Hi Heinrich.
> 
>  Thanks for the patch. As far as I can tell the Milk-V
>  documentation[1] is pretty consistent in calling the version without eMMC
> "Milk-V Mars CM Lite"
>  and the version with eMMC just "Milk-V Mars CM". So I'd prefer the
>  model, compatible and filenames suggested below.
> 
>  [1]:
>  https://milkv.io/docs/mars/compute-module/introduction#design-philo
>  sophy
> 
> >>>
> >>> Are there any actual differences that need representation in the dtb
> >>> file for downstream OS different from Milk-V Mars to Milk-V Mars CM
> >>> (or CM Lite)?
> >>>
> >>> I did find this vendor repo commit "kernel: dts reconfig sdio0 for
> >>> SDCard version"
> >>> https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea0659899
> >>> 5db99dd252ee439c42b9c1a9 but it does not seem necessary in
> >>> mainline Linux, SD Card is working without changes.
> >>>
> >>> It was necessary for U-Boot and the Mars CM Lite with SD Card to
> >>> apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure
> >>> sdio0 as mars-cm sdcard version"
> >>> https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f7
> >>> 2ecf1e2947dfeb2c66e5035fce90
> >>
> >> This is what is patched in fdt_fixup_marc().
> >
> > That's the Mars fixup with a conditional for the s/GPIO62/GPIO22/ of
> > CM Lite;  which Linux seems not to mind either way so long as this was
> > done at the U-Boot phase, it is functional for eMMC/SD mmc access with
> > unmodified visionfive2 1.3b dtb (GPIO62 pinmux) from Linux.
> >
> > It is not clear to me why in vendor U-Boot this is s/GPIO62/GPIO22/
> > but in vendor Linux kernel this is s/GPIO62/GPIO24/ ? It seems not
> > needed (in Linux).
> 
> According to the schematics GPIO22 is connected to SD_PWR_ON on the the
> low speed connector both on the Mars CM and the Mars CM Lite. GPIO62 is
> connected to SDMMC_RST_N on the eMMC. Both the SD-card and the eMMC
> are connected to SDI0. This is why only one of them can be usable.
> 
> GPIO024 is used for the MIPI camera interface.
> 
> I guess unless you reset the SD-card or eMMC GPIO062 and GPI022 are not used
> and this is why Linux is working in both configurations.
> 
> >
> >>
> >>>
> >>> Then also there is some mention about PMIC and renamed i2c
> >>> reference, already obsolete. That's all, is there more to it?
> >>> Possibly a dtb for Mars is enough to also be used on Mars CM and Mars 
> >>> Lite?
> >>
> >> Looking at the schematics the biggest difference between the Mars and
> >> the Mars CM (Lite) is on the USB side. The Mars board has USB 3.0 via
> >> a PCIe lane and a VIA VL805/806 while the Mars CM has USB directly
> >> via the SoC.
> >>
> >> To add USB support for the Mars CM we will need an adapted device-tree.
> >
> > Mars also needs this direct-to-SoC USB support, as its USB ports are a
> > mix of VL805 and directly via the SoC. This can be the same for Mars
> > and Mars CM/Lite.
> 
> The schematics say:
> 
> "One USB Controller only, supports either USB 2.0 or USB 3.0."
> 
> This sounds to me like you cannot have both in functional state.
> 
> Maybe Minda or Hal know more?
> 
> Best regards
> 
> Heinrich
> 
usb 3.0 PHY and PCIe0 using the same PHY. (2 PCIe + USB 2.0 or 1PCIe + USB 
3.0/2.0)
Now I have upstreamed the usb controller driver.

> >
> > See this photo from
> > https://milkv.io/docs/mars/getting-started/bootloader what highlights
> > this direct SoC USB port of Milk-V Mars:
> > https://milkv.io/assets/images/mars-usb-port-a-b48fe1ff1003539d42bf5e1
> > dde1725a3.jpg
> >
> > The over-current errata
> > https://doc-en.rvspace.org/VisionFive2/DG_USB/JH7110_SDK/usb_overcurre
> > nt_debug.html suggests "please modify the above settings during the
> > U-Boot phase".
> >
> > -E
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>>
> > Signed-off-by: Heinrich Schuchardt
> > 
> > ---
> >board/starfive/visionfive2/spl.c  | 27
> ++-
> >.../visionfive2/starfive_visionfive2.c| 11 +++-
> >2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/starfive/visionfive2/spl.c
> > b/board/starfive/visionfive2/spl.c
> > index 45848db6d8b..bb0f28d7aad 100644
> > --- a/board/starfive/visionfive2/spl.c
> > +++ b/board/starfive/visionfive2/spl.c
> > @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt)
> > }
> >}
> >
> > +void spl_fdt_fixup_marc(void *fdt) {
> > + const char *compat;
> 

Re: [PATCH] board: starfive: support Pine64 Star64 board

2024-05-06 Thread E Shattow
Hi,

On Mon, May 6, 2024 at 8:30 AM H Bell  wrote:
>
> Similar to the Milk-V Mars, The Star64 board contains few differences to the
> VisionFive 2 boards, so can be part of the same U-boot build.
>
> Signed-off-by: Henry Bell 
> Cc: ycli...@andestech.com
> Cc: heinrich.schucha...@canonical.com
> ---
>  board/starfive/visionfive2/spl.c  | 52 +++
>  .../visionfive2/starfive_visionfive2.c|  4 ++
>  2 files changed, 56 insertions(+)
>
> diff --git a/board/starfive/visionfive2/spl.c 
> b/board/starfive/visionfive2/spl.c
> index ca61b5be22..b8d29a02af 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -226,6 +226,56 @@ void spl_fdt_fixup_version_b(void *fdt)
> }
>  }
>
> +void spl_fdt_fixup_star64(void *fdt)
> +{
> +   static const char compat[] = "starfive,star64\0starfive,jh7110";

Should be "pine64,star64\nstarfive,jh7110" ?

> +   u32 phandle;
> +   u8 i;
> +   int offset;
> +   int ret;
> +
> +   fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, 
> sizeof(compat));
> +   fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
> +  "Pine64 Star64");
> +
> +   /* gmac0 */
> +   offset = fdt_path_offset(fdt, "/soc/clock-controller@1700");
> +   phandle = fdt_get_phandle(fdt, offset);
> +   offset = fdt_path_offset(fdt, "/soc/ethernet@1603");
> +
> +   fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle);
> +   fdt_appendprop_u32(fdt, offset, "assigned-clocks", 
> JH7110_AONCLK_GMAC0_TX);
> +   fdt_setprop_u32(fdt, offset,  "assigned-clock-parents", phandle);
> +   fdt_appendprop_u32(fdt, offset,  "assigned-clock-parents",
> +  JH7110_AONCLK_GMAC0_RMII_RTX);
> +
> +   /* gmac1 */
> +   offset = fdt_path_offset(fdt, "/soc/clock-controller@1302");
> +   phandle = fdt_get_phandle(fdt, offset);
> +   offset = fdt_path_offset(fdt, "/soc/ethernet@1604");
> +
> +   fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle);
> +   fdt_appendprop_u32(fdt, offset, "assigned-clocks", 
> JH7110_SYSCLK_GMAC1_TX);
> +   fdt_setprop_u32(fdt, offset,  "assigned-clock-parents", phandle);
> +   fdt_appendprop_u32(fdt, offset,  "assigned-clock-parents",
> +  JH7110_SYSCLK_GMAC1_RMII_RTX);
> +
> +   for (i = 0; i < ARRAY_SIZE(starfive_verb); i++) {
> +   offset = fdt_path_offset(fdt, starfive_verb[i].path);
> +
> +   if (starfive_verb[i].value)
> +   ret = fdt_setprop_u32(fdt, offset,  
> starfive_verb[i].name,
> + dectoul(starfive_verb[i].value, 
> NULL));

Using the fishwaldo repo Star64_devel branch Linux sources as my reference
https://github.com/Fishwaldo/Star64_linux
the drive strength is 3600 and looking at StarFive repo:
https://github.com/starfive-tech/u-boot/blob/223ac8b1e907924d3891b3be1b2f6620b56bff31/arch/riscv/dts/starfive_visionfive2.dts#L323
from "rgmii_sw_dr_rxc = <0x6>;" (7th enum is 3600).  However the dev
dts still refers to 0x7 ( i.e. " motorcomm,rx-clk-drv-microamp =
<3970>;")
https://github.com/starfive-tech/u-boot/blob/223ac8b1e907924d3891b3be1b2f6620b56bff31/arch/riscv/dts/starfive_devkits.dts#L289

Also the delay inverts differ somewhat. Marked-up
arch/riscv/boot/dts/starfive/jh7110-pine64-star64.dtsi from the above
repo:

 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@0 {
rgmii_sw_dr_2 = <0x0>;   switch drive 1.8V operation
rgmii_sw_dr = <0x3>; switch drive 4th enum is 2910
rgmii_sw_dr_rxc = <0x6>; switch clock drive rx current
7th enum is 3600
rxc_dly_en = <0>;   0 (disabled) 1900ps rxc
clock additional delay added to configured rx delay (default is
disabled).  Default tx/rx delay value is 1950ps.
rx_delay_sel = <0xa>;1500 at 1000Mbps
tx_delay_sel_fe = <5>;750 at 10/100Mbps
tx_delay_sel = <0xa>;1500 at 1000Mbps
tx_inverted_10 = <0x1>;   true motorcomm,tx-clk-10-inverted
tx_inverted_100 = <0x1>;  true motorcomm,tx-clk-100-inverted
tx_inverted_1000 = <0x1>; true motorcomm,tx-clk-1000-inverted
};
};

 {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
phy1: ethernet-phy@1 {
rgmii_sw_dr_2 = <0x0>;switch drive 2 1.8V operation
rgmii_sw_dr = <0x3>;  switch drive 4th enum is 2910
rgmii_sw_dr_rxc = <0x6>;  switch clock drive rx
current 7th enum is 3600
rxc_dly_en = <0>;  0 (disabled) 1900ps rxc
clock additional delay added to configured rx delay (default is
disabled).  Default tx/rx delay value is 1950ps.
rx_delay_sel = <0x2>;300 at 1000Mbps
 

[PATCH] doc/sphinx: Bump Jinja2 to 3.1.4

2024-05-06 Thread Tom Rini
While we unlikely to have an issue with CVE-2024-22195, it is simple
enough to bump our version of Jinja2 to receive the fix, do so.

Reported-by: GitHub dependabot
Signed-off-by: Tom Rini 
---
 doc/sphinx/requirements.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index 5b4df36804b5..426f41e1a028 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -5,7 +5,7 @@ charset-normalizer==3.3.2
 docutils==0.20.1
 idna==3.7
 imagesize==1.4.1
-Jinja2==3.1.3
+Jinja2==3.1.4
 MarkupSafe==2.1.3
 packaging==23.2
 Pygments==2.17.2
-- 
2.34.1



[ANN] U-Boot v2024.07-rc2 released

2024-05-06 Thread Tom Rini
Hey all,

It's release day and here is -rc2. Looking at my own queue, I think
I've got everything from there I intend to go in this release. That
said, there's still a few PRs I would like to see from others before it
gets too much later and if people know of bug fixes that are outstanding
still please let me know so I can take a look.

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

As this is -rc2 I'm opening the -next branch and have synced that to
master. I will be pulling in the large series I posted recently to
remove include/common.h very soon, and then start grabbing other
changes. I expect this to have minimal impact on others and should be
easily manually resolved as needed.

I hope to remain on schedule and that means the rest of the rcs every
other Monday, and with final release on Monday, July 1st, 2024. Thanks
all!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read

2024-05-06 Thread Michael Nazzareno Trimarchi
Hi Ravi

On Mon, May 6, 2024 at 7:33 PM Ravi Minnikanti  wrote:
>
> On 5/6/24 00:35, Michael Nazzareno Trimarchi wrote:
> > Hi Ravi
> >
> > On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti  
> > wrote:
> >>
> >> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote:
> >>
> >>> --
> >>> On Mon, Apr 29, 2024 at 6:22 PM Chris Packham  
> >>> wrote:
> 
>  On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti 
>   wrote:
> >
> > Once a page is read with higher bitflips all subsequent reads
> > are returning the same bitflip value even though they have none.
> > max_bitflip variable is not being reset to 0 across page reads.
> >
> > This is causing problems like incorrectly
> > marking erase blocks bad by UBI and causing read failures.
> >
> > Verified the change with both MTD reads and UBI.
> > This change is inline with other NFC drivers.
> >
> > Sample error log where a block is marked bad incorrectly:
> >
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0: run torture test for PEB 125
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> > must be bad
> > ubi0 error: erase_worker: failed to erase PEB 125, error -5
> > ubi0: mark PEB 125 as bad
> >
> > Signed-off-by: rminnikanti 
> 
>  Looks good to me
> 
>  Reviewed-by: Chris Packham 
> 
> > ---
> >  drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c 
> > b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > index 1d9a6d107b..d2a4faad56 100644
> > --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > @@ -800,6 +800,11 @@ static void prepare_start_command(struct 
> > pxa3xx_nand_info *info, int command)
> > info->ecc_err_cnt   = 0;
> > info->ndcb3 = 0;
> > info->need_wait = 0;
> > +   /*
> > +* Reset max_bitflips to zero. Once command is complete,
> > +* max_bitflips for this READ is returned in ecc.read_page()
> > +*/
> > +   info->max_bitflips  = 0;
> >
> >>>
> >>> Why this should not be put to 0 in read_page instead on 
> >>> prepare_start_command?
> >>>
> >>> Michael
> >>>
> >>
> >> ecc.read_page is invoked after the read command execution.
> >> First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page 
> >> is invoked
> >> to read the page from buffer. So, by the time read_page is invoked, 
> >> info->max_bitflips
> >> must already have the bit flip value.
> >>
> >
> > All the other implementation has a slight different way to handle.
> > From what you said the reset should
> > be done on for NAND_CMD_READ0 command and should be sufficient.
> > Technically should be moved
> > in switch and not unconditionally.
> >
> > Michael
> >
>
> max_bitflip is not being reset to 0 across page reads.
> Once a page is read with higher bitflips all subsequent reads
> are returning the same bitflip value even though they have none.
>
> This is causing problems like incorrectly
> marking erase blocks bad by UBI and read failures.
>
> Tested it with both MTD reads and UBI attach.
> This change is inline with other NFC drivers.
>
> Sample error log where a block is marked bad incorrectly:
>
> ubi0: fixable bit-flip detected at PEB 125
> ubi0: run torture test for PEB 125
> ubi0: fixable bit-flip detected at PEB 125
> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> must be bad
> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> ubi0: mark PEB 125 as bad
>
> Signed-off-by: rminnikanti 
> ---
>  drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c 
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index 1d9a6d107b..97f250483f 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -803,6 +803,11 @@ static void prepare_start_command(struct 
> pxa3xx_nand_info *info, int command)
>
> switch (command) {
> case NAND_CMD_READ0:
> +   /*
> +* Reset max_bitflips to zero. Once command is complete,
> +* max_bitflips for this READ is returned in ecc.read_page()
> +*/
> +   info->max_bitflips = 0;
> case NAND_CMD_READOOB:
> case NAND_CMD_PAGEPROG:
> if (!info->force_raw)
> --
> 2.17.1
>
> Thanks Michael. Fixed it.
>
> >> Thanks, Ravi.
> >>
> > switch (command) {
> > case NAND_CMD_READ0:
> > --
> > 2.17.1
> >>>
> >>
> >
> >

Acked-by: Michael Trimarchi 



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170

Re: [PATCH] kconfig: default to zero if int/hex symbol lacks default property

2024-05-06 Thread Tom Rini
On Sun, May 05, 2024 at 03:53:53PM +0200, Yoann Congal wrote:

> From: Masahiro Yamada 
> 
> This is a cherry-pick from the kernel commit:
> 6262afa10ef7c (kconfig: default to zero if int/hex symbol lacks default 
> property, 2023-11-26)
> 
> When a default property is missing in an int or hex symbol, it defaults
> to an empty string, which is not a valid symbol value.
> 
> It results in an incorrect .config, and can also lead to an infinite
> loop in scripting.
> 
> Use "0" for int and "0x0" for hex as a default value.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Yoann Congal 
> 
> Signed-off-by: Yoann Congal 
> ---
> Added context that was not in the upstream commit:
> The infinite loop case happens with a configuration defined like this
> (a hex config without a valid default value):
>   config HEX_TEST
>   hex "Hex config without default"
> 
> And using:
>   $ make oldconfig < /dev/null
>   scripts/kconfig/conf  --oldconfig Kconfig
>   *
>   * General setup
>   *
> 
>   Error in reading or end of file.
> 
>   Error in reading or end of file.
>   Hex config without default (HEX_TEST) [] (NEW)
> 
>   Error in reading or end of file.
>   Hex config without default (HEX_TEST) [] (NEW)
>   # This loops forever
> 
> NB: Scripted config manipulation often call make with /dev/null as
> stdin (Yocto recipe, CI build, ...)
> 
> This was discovered when working on Yocto bug:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14136

I'm surprised this was accepted. In the past I've wanted to avoid this
kind of change in Kconfig because while the empty string can be easily
be checked in the code as "user didn't really configure this, do
nothing" a value of zero is a valid option in these cases and so then in
the code we need a bool symbol to decide if the hex/int symbol is set or
not.

Today this is less of an issue than it used to be in U-Boot with
everything CONFIG-related migrated to Kconfig and so there's no longer
the question of if we missed migrating a file that defined the value but
there's still places we have in the code where hex symbol is undefined
is not the same thing as hex symbol is 0x0.

Is there a specific use case you have for this in U-Boot? It's been a
while, but it's also been cases of newly introduced symbols in Kconfig
files with incorrect dependencies, where the infinite loop in kconfig
happened, CI failed and we caught the problem.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read

2024-05-06 Thread Ravi Minnikanti
On 5/6/24 00:35, Michael Nazzareno Trimarchi wrote:
> Hi Ravi
> 
> On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti  
> wrote:
>>
>> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote:
>>
>>> --
>>> On Mon, Apr 29, 2024 at 6:22 PM Chris Packham  
>>> wrote:

 On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti  
 wrote:
>
> Once a page is read with higher bitflips all subsequent reads
> are returning the same bitflip value even though they have none.
> max_bitflip variable is not being reset to 0 across page reads.
>
> This is causing problems like incorrectly
> marking erase blocks bad by UBI and causing read failures.
>
> Verified the change with both MTD reads and UBI.
> This change is inline with other NFC drivers.
>
> Sample error log where a block is marked bad incorrectly:
>
> ubi0: fixable bit-flip detected at PEB 125
> ubi0: run torture test for PEB 125
> ubi0: fixable bit-flip detected at PEB 125
> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> must be bad
> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> ubi0: mark PEB 125 as bad
>
> Signed-off-by: rminnikanti 

 Looks good to me

 Reviewed-by: Chris Packham 

> ---
>  drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c 
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index 1d9a6d107b..d2a4faad56 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -800,6 +800,11 @@ static void prepare_start_command(struct 
> pxa3xx_nand_info *info, int command)
> info->ecc_err_cnt   = 0;
> info->ndcb3 = 0;
> info->need_wait = 0;
> +   /*
> +* Reset max_bitflips to zero. Once command is complete,
> +* max_bitflips for this READ is returned in ecc.read_page()
> +*/
> +   info->max_bitflips  = 0;
>
>>>
>>> Why this should not be put to 0 in read_page instead on 
>>> prepare_start_command?
>>>
>>> Michael
>>>
>>
>> ecc.read_page is invoked after the read command execution.
>> First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page 
>> is invoked
>> to read the page from buffer. So, by the time read_page is invoked, 
>> info->max_bitflips
>> must already have the bit flip value.
>>
> 
> All the other implementation has a slight different way to handle.
> From what you said the reset should
> be done on for NAND_CMD_READ0 command and should be sufficient.
> Technically should be moved
> in switch and not unconditionally.
> 
> Michael
> 

max_bitflip is not being reset to 0 across page reads.
Once a page is read with higher bitflips all subsequent reads
are returning the same bitflip value even though they have none.

This is causing problems like incorrectly
marking erase blocks bad by UBI and read failures.

Tested it with both MTD reads and UBI attach.
This change is inline with other NFC drivers.

Sample error log where a block is marked bad incorrectly:

ubi0: fixable bit-flip detected at PEB 125
ubi0: run torture test for PEB 125
ubi0: fixable bit-flip detected at PEB 125
ubi0 error: torture_peb: read problems on freshly erased PEB 125,
must be bad
ubi0 error: erase_worker: failed to erase PEB 125, error -5
ubi0: mark PEB 125 as bad

Signed-off-by: rminnikanti 
---
 drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c 
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 1d9a6d107b..97f250483f 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -803,6 +803,11 @@ static void prepare_start_command(struct pxa3xx_nand_info 
*info, int command)
 
switch (command) {
case NAND_CMD_READ0:
+   /*
+* Reset max_bitflips to zero. Once command is complete,
+* max_bitflips for this READ is returned in ecc.read_page()
+*/
+   info->max_bitflips = 0;
case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
if (!info->force_raw)
-- 
2.17.1

Thanks Michael. Fixed it.

>> Thanks, Ravi.
>>
> switch (command) {
> case NAND_CMD_READ0:
> --
> 2.17.1
>>>
>>
> 
> 


Re: [PATCH v2 03/22] clk: rockchip: rk3399: Improve support for SCLK_PCIEPHY_REF clock

2024-05-06 Thread Quentin Schulz

Hi Jonas,

On 5/6/24 5:17 PM, Jonas Karlman wrote:

Hi Quentin,

On 2024-05-06 13:07, Quentin Schulz wrote:

Hi Jonas,

On 5/1/24 6:22 PM, Jonas Karlman wrote:

rk3399-nanopi-4.dtsi try to set parent of and set rate to 100 MHz of the
SCLK_PCIEPHY_REF clock.

The existing enable/disable ops for SCLK_PCIEPHY_REF currently force
use of 24 MHz parent and rate.

Add improved support for setting parent and rate of the pciephy refclk
to driver to better support assign-clock props for pciephy refclk in DT.

This limited implementation only support setting 24 or 100 MHz rate,
and expect npll and clk_pciephy_ref100m divider to use default values.

Signed-off-by: Jonas Karlman 
---
v2: Implement partial instead of dummy support for SCLK_PCIEPHY_REF
---
   drivers/clk/rockchip/clk_rk3399.c | 59 +--
   1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 5934771b4096..0b3223611a32 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -926,6 +926,26 @@ static ulong rk3399_saradc_set_clk(struct rockchip_cru 
*cru, uint hz)
return rk3399_saradc_get_clk(cru);
   }
   
+static ulong rk3399_pciephy_get_clk(struct rockchip_cru *cru)

+{
+   if (readl(>clksel_con[18]) & BIT(10))
+   return 100 * MHz;
+   else
+   return OSC_HZ;


Could avoid the else since all if blocks return, no other logic than the
one matching the else can reach that part of the code.

Therefore:

"""
if (readl(>clksel_con[18]) & BIT(10))
  return 100 * MHz;

return OSC_HZ;
"""

works just as well.


I was considering above format at first, but chose to align return
statements for some reason.

I can change to this format in a v3, if needed :-)



Just a matter of taste :)



Could also be

"""
return (readl(>clksel_con[18]) & BIT(10)) ? 100 * MHz : OSC_HZ;
"""

[...]

+static int __maybe_unused rk3399_pciephy_set_parent(struct clk *clk,
+   struct clk *parent)
+{
+   struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
+   const char *clock_output_name;
+   int ret;
+
+   if (parent->dev == clk->dev && parent->id == SCLK_PCIEPHY_REF100M) {
+   rk_setreg(>cru->clksel_con[18], BIT(10));
+   return 0;
+   }
+
+   ret = dev_read_string_index(parent->dev, "clock-output-names",
+   parent->id, _output_name);


Are you sure this works?


It should work for the clk reference I tested, <>, where the id
will be 0, it should also work for e.g. < 1>, id will be 1.

And if a / clk is referenced those nodes do not have the
clock-output-names prop, so ret should be -EINVAL (or -ENODATA).



Considering that parent->id seems to store unique ids, like 167 for
SCLK_PCIEPHY_REF100M, I doubt we should be using it for
dev_read_string_index

As per documentation:

"""
/**
   * dev_read_string_index() - obtain an indexed string from a string list
   *
   * @dev: device to examine
   * @propname: name of the property containing the string list
   * @index: index of the string to return
   * @outp: return location for the string
   *
   * Return:
   *   length of string, if found or -ve error value if not found
   */
int dev_read_string_index(const struct udevice *dev, const char *propname,
  int index, const char **outp);
"""

So index here means the (index+1)'th string in the list of strings under
the "propname" DT property, I doubt we have properties with 167+ strings
in them?


I would expect the function to return -EINVAL or -ENODATA if it is called
with an out-of-bounds index value.



-ENODATA it seems. -EINVAL if the property doesn't exist.



I realize that rk3399_gmac_set_parent also uses this, so I'm a bit
puzzled right now...

Don't you want to use

dev_read_stringlist_search(parent->dev, "clock-output-names", "xin24m")

instead?


I think the implementation is correct and is what other rk clk drivers
do for gmac set parent ops.

Using dev_read_stringlist_search() could possible match a name for
"wrong" clock, e.g:

clk_ref: clock {
#clock-cells = <1>;
clock-output-names = "xin32k", "xin24m";
};

here only <_ref 1> should match and not <_ref 0>.



Ah well, one more brain fart :) I somehow mixed things up and was 
thinking about the values in clocks/assigned-clocks in one node needing 
to match the offset in clock-names of that same node, which made no 
sense. But we're talking about different things here :)


I guess it's just a matter of taste between the implementation in your 
patch and the inverted logic which tries to find xin24m in 
clock-output-names and checks its index matches parent->id. Consistency 
is preferred, and the former is already used in other places, so let's 
keep this.


Thanks for taking the time to explain.

This does seem reasonable to me, so:

Reviewed-by: Quentin Schulz 


Re: [PATCH v2 1/4] binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing

2024-05-06 Thread Marek Vasut

On 5/6/24 1:52 PM, Francesco Dolcini wrote:

Hello Marek,

On Fri, May 03, 2024 at 03:05:09AM +0200, Marek Vasut wrote:

Add new binman etype which allows signing both the SPL and fitImage sections
of i.MX8M flash.bin using CST. There are multiple DT properties which govern
the signing process, nxp,loader-address is the only mandatory one which sets
the SPL signature start address without the imx8mimage header, this should be
SPL text base. The key material can be configured using optional DT properties
nxp,srk-table, nxp,csf-crt, nxp,img-crt, all of which default the key material
names generated by CST tool scripts. The nxp,unlock property can be used to
unlock CAAM access in SPL section.

Signed-off-by: Marek Vasut 


I was not able to test or really look into your series [1], however I can
relate with a comment from Tim Harvey.

I think is important to keep in mind that that signing cannot be done
with key material that is in-tree, because well, that's private, and I
think we should not force people to branch to properly sign the
binaries.

I think that it would be valuable to share how do you foresee this used
in a real environment.


I am open to discussion, really.

Currently the most basic approach is implemented -- plug in key material 
either by copying it into build directory, or creating a symlink, or 
adjusting the DT to specify full path to key material.


I am sure this can be expanded to cover other use cases ?


[PATCH] board: starfive: support Pine64 Star64 board

2024-05-06 Thread H Bell
Similar to the Milk-V Mars, The Star64 board contains few differences to the
VisionFive 2 boards, so can be part of the same U-boot build.

Signed-off-by: Henry Bell 
Cc: ycli...@andestech.com
Cc: heinrich.schucha...@canonical.com
---
 board/starfive/visionfive2/spl.c  | 52 +++
 .../visionfive2/starfive_visionfive2.c|  4 ++
 2 files changed, 56 insertions(+)

diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index ca61b5be22..b8d29a02af 100644
--- a/board/starfive/visionfive2/spl.c
+++ b/board/starfive/visionfive2/spl.c
@@ -226,6 +226,56 @@ void spl_fdt_fixup_version_b(void *fdt)
}
 }
 
+void spl_fdt_fixup_star64(void *fdt)
+{
+   static const char compat[] = "starfive,star64\0starfive,jh7110";
+   u32 phandle;
+   u8 i;
+   int offset;
+   int ret;
+
+   fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, 
sizeof(compat));
+   fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
+  "Pine64 Star64");
+
+   /* gmac0 */
+   offset = fdt_path_offset(fdt, "/soc/clock-controller@1700");
+   phandle = fdt_get_phandle(fdt, offset);
+   offset = fdt_path_offset(fdt, "/soc/ethernet@1603");
+
+   fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle);
+   fdt_appendprop_u32(fdt, offset, "assigned-clocks", 
JH7110_AONCLK_GMAC0_TX);
+   fdt_setprop_u32(fdt, offset,  "assigned-clock-parents", phandle);
+   fdt_appendprop_u32(fdt, offset,  "assigned-clock-parents",
+  JH7110_AONCLK_GMAC0_RMII_RTX);
+
+   /* gmac1 */
+   offset = fdt_path_offset(fdt, "/soc/clock-controller@1302");
+   phandle = fdt_get_phandle(fdt, offset);
+   offset = fdt_path_offset(fdt, "/soc/ethernet@1604");
+
+   fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle);
+   fdt_appendprop_u32(fdt, offset, "assigned-clocks", 
JH7110_SYSCLK_GMAC1_TX);
+   fdt_setprop_u32(fdt, offset,  "assigned-clock-parents", phandle);
+   fdt_appendprop_u32(fdt, offset,  "assigned-clock-parents",
+  JH7110_SYSCLK_GMAC1_RMII_RTX);
+
+   for (i = 0; i < ARRAY_SIZE(starfive_verb); i++) {
+   offset = fdt_path_offset(fdt, starfive_verb[i].path);
+
+   if (starfive_verb[i].value)
+   ret = fdt_setprop_u32(fdt, offset,  
starfive_verb[i].name,
+ dectoul(starfive_verb[i].value, 
NULL));
+   else
+   ret = fdt_setprop_empty(fdt, offset, 
starfive_verb[i].name);
+
+   if (ret) {
+   pr_err("%s set prop %s fail.\n", __func__, 
starfive_verb[i].name);
+   break;
+   }
+   }
+}
+
 void spl_perform_fixups(struct spl_image_info *spl_image)
 {
u8 version;
@@ -252,6 +302,8 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
spl_fdt_fixup_version_b(spl_image->fdt_addr);
break;
};
+   } else if (!strncmp(product_id, "STAR64", 6)) {
+   spl_fdt_fixup_star64(spl_image->fdt_addr);
} else {
pr_err("Unknown product %s\n", product_id);
};
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c 
b/board/starfive/visionfive2/starfive_visionfive2.c
index a86bca533b..93bc8b5c55 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -23,6 +23,8 @@ DECLARE_GLOBAL_DATA_PTR;
"starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
 #define FDTFILE_VISIONFIVE2_1_3B \
"starfive/jh7110-starfive-visionfive-2-v1.3b.dtb"
+#define FDTFILE_PINE64_STAR64 \
+   "starfive/pine64-star64.dtb"
 
 /* enable U74-mc hart1~hart4 prefetcher */
 static void enable_prefetcher(void)
@@ -78,6 +80,8 @@ static void set_fdtfile(void)
fdtfile = FDTFILE_VISIONFIVE2_1_3B;
break;
}
+   } else if (!strncmp(product_id, "STAR64", 6)) {
+   fdtfile = FDTFILE_PINE64_STAR64;
} else {
log_err("Unknown product\n");
return;
-- 
2.44.0



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

2024-05-06 Thread Alexey Romanov
Hello! Ping.

On Mon, Mar 25, 2024 at 05:41:42PM +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].
> 
> --- 
> 
> Changes V1 -> V2 [2]:
> 
>  - Rebased over mtdblock v2 patchset [3].
>  - Compile UBI partitions support only if CONFIG_BLK option
>is enabled.
> 
> - Links:
> 
>   [1] 
> https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
>   [2] 
> https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
>   [3] 
> https://lore.kernel.org/all/20240307130726.1582487-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 |   8 ++-
>  drivers/mtd/ubi/Makefile|   1 +
>  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, 332 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 v3 0/3] Introduce mtdblock device

2024-05-06 Thread Alexey Romanov
Hello Michael,

On Thu, Apr 11, 2024 at 06:14:29PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> I will review tomorrow, I need have a time window to test even on my board

Any news?

> 
> Mihcael
> 
> On Thu, Apr 11, 2024 at 6:09 PM Alexey Romanov
>  wrote:
> >
> > Hello! Ping.
> >
> > On Thu, Apr 04, 2024 at 01:58:10PM +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.
> > >
> > > Changes V2 -> V3 [2]:
> > >
> > >   - Rebased over [3].
> > >   - Rename mtd_bread/bwrite -> mtd_blk_read/write.
> > >   - Fix GPL-2.0 license short name definiton in headers.
> > >   - Add empty line after MTD_ENTRY_NUMBERS define.
> > >
> > > 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/
> > >   - [3] 
> > > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u
> > >
> > > Alexey Romanov (3):
> > >   disk: support MTD partitions
> > >   drivers: introduce mtdblock abstraction
> > >   spinand: bind mtdblock
> > >
> > >  disk/part.c |   3 +-
> > >  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  |   3 +
> > >  9 files changed, 336 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/mtd/mtdblock.c
> > >
> > > --
> > > 2.34.1
> > >
> >
> > --
> > Thank you,
> > Alexey
> 
> 
> 
> -- 
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com

-- 
Thank you,
Alexey

Re: [PATCH v2 03/22] clk: rockchip: rk3399: Improve support for SCLK_PCIEPHY_REF clock

2024-05-06 Thread Jonas Karlman
Hi Quentin,

On 2024-05-06 13:07, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 5/1/24 6:22 PM, Jonas Karlman wrote:
>> rk3399-nanopi-4.dtsi try to set parent of and set rate to 100 MHz of the
>> SCLK_PCIEPHY_REF clock.
>>
>> The existing enable/disable ops for SCLK_PCIEPHY_REF currently force
>> use of 24 MHz parent and rate.
>>
>> Add improved support for setting parent and rate of the pciephy refclk
>> to driver to better support assign-clock props for pciephy refclk in DT.
>>
>> This limited implementation only support setting 24 or 100 MHz rate,
>> and expect npll and clk_pciephy_ref100m divider to use default values.
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>> v2: Implement partial instead of dummy support for SCLK_PCIEPHY_REF
>> ---
>>   drivers/clk/rockchip/clk_rk3399.c | 59 +--
>>   1 file changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/rockchip/clk_rk3399.c 
>> b/drivers/clk/rockchip/clk_rk3399.c
>> index 5934771b4096..0b3223611a32 100644
>> --- a/drivers/clk/rockchip/clk_rk3399.c
>> +++ b/drivers/clk/rockchip/clk_rk3399.c
>> @@ -926,6 +926,26 @@ static ulong rk3399_saradc_set_clk(struct rockchip_cru 
>> *cru, uint hz)
>>  return rk3399_saradc_get_clk(cru);
>>   }
>>   
>> +static ulong rk3399_pciephy_get_clk(struct rockchip_cru *cru)
>> +{
>> +if (readl(>clksel_con[18]) & BIT(10))
>> +return 100 * MHz;
>> +else
>> +return OSC_HZ;
> 
> Could avoid the else since all if blocks return, no other logic than the 
> one matching the else can reach that part of the code.
> 
> Therefore:
> 
> """
> if (readl(>clksel_con[18]) & BIT(10))
>  return 100 * MHz;
> 
> return OSC_HZ;
> """
> 
> works just as well.

I was considering above format at first, but chose to align return
statements for some reason.

I can change to this format in a v3, if needed :-)

> 
> Could also be
> 
> """
> return (readl(>clksel_con[18]) & BIT(10)) ? 100 * MHz : OSC_HZ;
> """
> 
> [...]
>> +static int __maybe_unused rk3399_pciephy_set_parent(struct clk *clk,
>> +struct clk *parent)
>> +{
>> +struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
>> +const char *clock_output_name;
>> +int ret;
>> +
>> +if (parent->dev == clk->dev && parent->id == SCLK_PCIEPHY_REF100M) {
>> +rk_setreg(>cru->clksel_con[18], BIT(10));
>> +return 0;
>> +}
>> +
>> +ret = dev_read_string_index(parent->dev, "clock-output-names",
>> +parent->id, _output_name);
> 
> Are you sure this works?

It should work for the clk reference I tested, <>, where the id
will be 0, it should also work for e.g. < 1>, id will be 1.

And if a / clk is referenced those nodes do not have the
clock-output-names prop, so ret should be -EINVAL (or -ENODATA).

> 
> Considering that parent->id seems to store unique ids, like 167 for 
> SCLK_PCIEPHY_REF100M, I doubt we should be using it for 
> dev_read_string_index
> 
> As per documentation:
> 
> """
> /**
>   * dev_read_string_index() - obtain an indexed string from a string list
>   *
>   * @dev: device to examine
>   * @propname: name of the property containing the string list
>   * @index: index of the string to return
>   * @outp: return location for the string
>   *
>   * Return:
>   *   length of string, if found or -ve error value if not found
>   */
> int dev_read_string_index(const struct udevice *dev, const char *propname,
> int index, const char **outp);
> """
> 
> So index here means the (index+1)'th string in the list of strings under 
> the "propname" DT property, I doubt we have properties with 167+ strings 
> in them?

I would expect the function to return -EINVAL or -ENODATA if it is called
with an out-of-bounds index value.

> 
> I realize that rk3399_gmac_set_parent also uses this, so I'm a bit 
> puzzled right now...
> 
> Don't you want to use
> 
> dev_read_stringlist_search(parent->dev, "clock-output-names", "xin24m")
> 
> instead?

I think the implementation is correct and is what other rk clk drivers
do for gmac set parent ops.

Using dev_read_stringlist_search() could possible match a name for
"wrong" clock, e.g:

clk_ref: clock {
#clock-cells = <1>;
clock-output-names = "xin32k", "xin24m";
};

here only <_ref 1> should match and not <_ref 0>.

Regards,
Jonas

> 
> The rest looks good to me.
> 
> Cheers,
> Quentin



Re: [GIT PULL] Please pull u-boot-imx-master-20240505

2024-05-06 Thread Tom Rini
On Sun, May 05, 2024 at 04:11:39PM -0300, Fabio Estevam wrote:

> Hi Tom,
> 
> Please pull from u-boot-imx/master, thanks.
> The following changes since commit 2f1e76bcfee75b9f99ade63002c05ffaaec86afb:
> 
>   Merge branch '2024-05-02-assorted-updates' (2024-05-03 16:18:51 -0600)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
> tags/u-boot-imx-master-20240505
> 
> for you to fetch changes up to cecb5fbb42c8b3de3d5a7df40bc01d1fdf4731d3:
> 
>   crypto/fsl: Differentiate between CAAM and DCP in Kconfig entry (2024-05-05 
> 11:21:39 -0300)
> 
> u-boot-imx-master-20240505

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v5 6/6] doc: board: Add document for DFU boot on am62x SoCs

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

Both AM62 SK and beagleplay support DFU boot in a similar way now;
Document how to actually run DFU boot for both boards

Signed-off-by: Sjoerd Simons 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek  # on beagle play
Signed-off-by: Martyn Welch 
---
Changes in v5:
- Typographical corrections

Changes in v4:
- New patch

 doc/board/beagle/am62x_beagleplay.rst | 14 +-
 doc/board/ti/am62x_sk.rst | 37 +++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/doc/board/beagle/am62x_beagleplay.rst 
b/doc/board/beagle/am62x_beagleplay.rst
index 7784e62b0b..cdc610264e 100644
--- a/doc/board/beagle/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -268,7 +268,19 @@ for details.
  - USB Device Firmware Upgrade (DFU) mode
 
 To switch to SD card boot mode, hold the USR button while powering on
-with Type-C power supply, then release when power LED lights up.
+with a USB type C power supply, then release when power LED lights up.
+
+DFU based boot
+--
+
+To boot the board over DFU, ensure there is no SD card inserted with a
+bootloader. Hold the USR switch while plugging into the type C to boot into DFU
+mode. After power-on the build artifacts needs to be uploaded one by one with a
+tool like dfu-util.
+
+.. include::  ../ti/am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_dfu_boot
+:end-before: .. am62x_evm_rst_include_end_dfu_boot
 
 Debugging U-Boot
 
diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index b12dc85f06..d5f7fe3b03 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -105,6 +105,20 @@ Set the variables corresponding to this platform:
 
 * 3.1 R5:
 
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_spl_r5
+:end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* 3.1.1 Alternative build of R5 for DFU boot:
+
+As the SPL size can get too big when building with support for booting both
+from local storage *and* DFU an extra config fragment should be used to enable
+DFU support (and disable storage support)
+
+.. prompt:: bash $
+
+  export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config"
+
 .. include::  ../ti/k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
@@ -251,6 +265,29 @@ https://www.ti.com/lit/pdf/spruiv7 under the `Boot Mode 
Pins` section.
 
 For SW2 and SW1, the switch state in the "ON" position = 1.
 
+DFU based boot
+--
+
+To boot the board over DFU, set the switches to DFU mode and connect to the
+USB type C DRD port on the board. After power-on the build artifacts needs to 
be
+uploaded one by one with a tool like dfu-util.
+
+.. am62x_evm_rst_include_start_dfu_boot
+
+The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl
+upload. The next stages as exposed by U-Boot have target alts matching the name
+of the artifacts, for these a USB reset has to be done after each upload.
+
+When using dfu-util the following commands can be used to boot to a U-Boot 
shell:
+
+.. prompt:: bash $
+
+  dfu-util -a bootloader -D tiboot3.bin
+  dfu-util -R -a tispl -D tispl.bin
+  dfu-util -R -a u-boot.img -D u-boot.img
+
+.. am62x_evm_rst_include_end_dfu_boot
+
 Debugging U-Boot
 
 
-- 
2.43.0



[PATCH v5 5/6] beagleplay: Add DFU support

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

DFU mode on a beagleplay can be used via the Type-C connector by holding
the USR switch while powering on.

Configuration is already provided as fragments for both the A53 and R5
u-boot parts. Include the am62x_a53_usbdfu.config config. The
am62x_r5_usbdfu.config fragment needs to be added should DFU boot be
required as this will disable booting from persistent storage due to
binary size constraints.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
---
Changes in v5:
- Use existing config fragment for a53 DFU configuration
- Force usb0 into peripheral mode

Changes in v4:
- New patch

 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 9 +
 board/beagle/beagleplay/beagleplay.env   | 1 +
 configs/am62x_beagleplay_a53_defconfig   | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index fb2032068d..967a2bdcd1 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -54,6 +54,15 @@
>;
 };
 
+ {
+   bootph-all;
+};
+
+ {
+   dr_mode = "peripheral";
+   bootph-all;
+};
+
 #ifdef CONFIG_TARGET_AM625_A53_BEAGLEPLAY
 
 #define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
diff --git a/board/beagle/beagleplay/beagleplay.env 
b/board/beagle/beagleplay/beagleplay.env
index bbf6b925d0..8dbfc2f7d2 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 name_kern=Image
 console=ttyS2,115200n8
diff --git a/configs/am62x_beagleplay_a53_defconfig 
b/configs/am62x_beagleplay_a53_defconfig
index 4f1be1df59..ec62670d55 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -121,3 +121,5 @@ CONFIG_EXT4_WRITE=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_LZO=y
 CONFIG_EFI_SET_TIME=y
+
+#include 
-- 
2.43.0



[PATCH v5 4/6] configs: am62x_evm_*: Enable USB and DFU support

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

Provide config fragments to enable USB host as well as USB gadget and DFU
support for a53 and r5. This relevant fragment is included into the
am62x EVM a53 defconfig. For the r5, due to the smaller available size,
the config fragment also disables support for persistent storage to free
up space for USB support. This fragment needs to be included is DFU
booting is desired.

The CONFIG_DFU_SF option is placed in the defconfig rather than the
fragment as this is known not to be supported on all boards that can
support DFU.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
---
Changes in v5:
- Switch to config fragment for a53 most DFU configuration

Changes in v4:
- Move R5 dfu config to a config fragment rather then a full defconfig
- Don't enable XHCI for the R5 SPL, unneeded

Changes in v3:
- Run savedefconfig to adjust to more recent u-boot

Changes in v2:
- Create a seperate defconfig for R5



 configs/am62x_a53_usbdfu.config | 30 ++
 configs/am62x_evm_a53_defconfig |  2 ++
 configs/am62x_r5_usbdfu.config  | 28 
 3 files changed, 60 insertions(+)
 create mode 100644 configs/am62x_a53_usbdfu.config
 create mode 100644 configs/am62x_r5_usbdfu.config

diff --git a/configs/am62x_a53_usbdfu.config b/configs/am62x_a53_usbdfu.config
new file mode 100644
index 00..3a19cf2328
--- /dev/null
+++ b/configs/am62x_a53_usbdfu.config
@@ -0,0 +1,29 @@
+CONFIG_SYS_MALLOC_LEN=0x200
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_DFU=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000
+CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
+CONFIG_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_AM62=y
+CONFIG_USB_DWC3_AM62=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
+CONFIG_USB_GADGET_DOWNLOAD=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 6c708dcb05..16294a6a79 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -68,6 +68,7 @@ CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_DFU_SF=y
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
@@ -111,3 +112,5 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_EFI_SET_TIME=y
+
+#include 
diff --git a/configs/am62x_r5_usbdfu.config b/configs/am62x_r5_usbdfu.config
new file mode 100644
index 00..772bb2ab93
--- /dev/null
+++ b/configs/am62x_r5_usbdfu.config
@@ -0,0 +1,28 @@
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000
+CONFIG_MISC=y
+CONFIG_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_AM62=y
+CONFIG_USB_GADGET=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_SPL_DFU=y
+# CONFIG_SPL_MMC is not set
+# CONFIG_SPL_FS_FAT is not set
+# CONFIG_SPL_LIBDISK_SUPPORT is not set
+# CONFIG_SPL_SPI is not set
+# CONFIG_SPL_SYS_MALLOC is not set
+# CONFIG_CMD_GPT is not set
+# CONFIG_CMD_MMC is not set
+# CONFIG_CMD_FAT is not set
+# CONFIG_MMC_SDHCI is not set
-- 
2.43.0



[PATCH v5 3/6] arm: dts: k3-am625-sk: Enable usb port in u-boot

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

Enable usb0 in all boot phases for use with DFU

Signed-off-by: Sjoerd Simons 
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Martyn Welch 
---
Changes in v5:
- Forcing usb0 into peripheral mode reinstated

Changes in v4:
- Don't force usb0 into peripheral mode

Changes in v3:
- Enable usb nodes in all boot phases

Changes in v2:
- Only enable usb port 0 DFU in SPL

 arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index fa778b0ff4..1fc0d407cb 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -46,3 +46,12 @@
 _port2 {
status = "disabled";
 };
+
+ {
+   bootph-all;
+};
+
+ {
+   dr_mode = "peripheral";
+   bootph-all;
+};
-- 
2.43.0



[PATCH v5 2/6] board: ti: am62x: am62x: include env for DFU

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

Include standard TI K3 dfu environment

Signed-off-by: Sjoerd Simons 
Reviewed-by: Alexander Sverdlin 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek  # on beagle play
---
(no changes since v3)

Changes in v3:
- Add dfu via environment rather then config headers

Changes in v2:
- Minimize config changes to just DFU configuration

 board/ti/am62x/am62x.env | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 9cb186c2a0..09b9b16a3e 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 name_kern=Image
 console=ttyS2,115200n8
-- 
2.43.0



[PATCH v5 1/6] usb: dwc3: Add dwc3 glue driver for am62

2024-05-06 Thread Martyn Welch
From: Sjoerd Simons 

Add glue code for TI AM62 to the dwc3 driver; Most code adopted from
TI vendor u-boot code.

Signed-off-by: Sjoerd Simons 
Tested-by: Alexander Sverdlin 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek  # on beagle play
---
Changes in v5:
- No change

Changes in v4:
- Add config dependency on SYSCON
- Move defines and constants outside out of function scope

Changes in v2:
- Switch dwc3 glue to a seperate driver rather then in dwc-generic

 drivers/usb/dwc3/Kconfig |  14 
 drivers/usb/dwc3/Makefile|   1 +
 drivers/usb/dwc3/dwc3-am62.c | 125 +++
 3 files changed, 140 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-am62.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index c0c8c16fd9..0100723a68 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -37,6 +37,20 @@ config SPL_USB_DWC3_GENERIC
  Select this for Xilinx ZynqMP and similar Platforms.
  This wrapper supports Host and Peripheral operation modes.
 
+config SPL_USB_DWC3_AM62
+   bool "TI AM62 USB wrapper"
+   depends on SPL_DM_USB && SPL_USB_DWC3_GENERIC && SPL_SYSCON
+   help
+ Select this for TI AM62 Platforms.
+ This wrapper supports Host and Peripheral operation modes.
+
+config USB_DWC3_AM62
+   bool "TI AM62 USB wrapper"
+   depends on DM_USB && USB_DWC3_GENERIC && SYSCON
+   help
+ Select this for TI AM62 Platforms.
+ This wrapper supports Host and Peripheral operation modes.
+
 config USB_DWC3_MESON_G12A
bool "Amlogic Meson G12A USB wrapper"
depends on DM_USB && USB_DWC3 && ARCH_MESON
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 97b4f7191c..a46b6824ab 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -6,6 +6,7 @@ dwc3-y  := core.o
 
 obj-$(CONFIG_USB_DWC3_GADGET)  += gadget.o ep0.o
 
+obj-$(CONFIG_$(SPL_)USB_DWC3_AM62) += dwc3-am62.o
 obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_MESON_G12A)  += dwc3-meson-g12a.o
 obj-$(CONFIG_USB_DWC3_MESON_GXL)   += dwc3-meson-gxl.o
diff --git a/drivers/usb/dwc3/dwc3-am62.c b/drivers/usb/dwc3/dwc3-am62.c
new file mode 100644
index 00..99519602eb
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-am62.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI AM62 specific glue layer for DWC3
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dwc3-generic.h"
+
+#define USBSS_MODE_CONTROL 0x1c
+#define USBSS_PHY_CONFIG   0x8
+#define USBSS_PHY_VBUS_SEL_MASKGENMASK(2, 1)
+#define USBSS_PHY_VBUS_SEL_SHIFT   1
+#define USBSS_MODE_VALID   BIT(0)
+#define PHY_PLL_REFCLK_MASKGENMASK(3, 0)
+static const int dwc3_ti_am62_rate_table[] = { /* in KHZ */
+   9600,
+   1,
+   12000,
+   19200,
+   2,
+   24000,
+   25000,
+   26000,
+   38400,
+   4,
+   58000,
+   5,
+   52000,
+};
+
+static void dwc3_ti_am62_glue_configure(struct udevice *dev, int index,
+   enum usb_dr_mode mode)
+{
+   struct clk usb2_refclk;
+   int rate_code, i, ret;
+   unsigned long rate;
+   u32 reg;
+   void *usbss;
+   bool vbus_divider;
+   struct regmap *syscon;
+   struct ofnode_phandle_args args;
+
+   usbss = dev_remap_addr_index(dev, 0);
+   if (IS_ERR(usbss)) {
+   dev_err(dev, "can't map IOMEM resource\n");
+   return;
+   }
+
+   ret = clk_get_by_name(dev, "ref", _refclk);
+   if (ret) {
+   dev_err(dev, "can't get usb2_refclk\n");
+   return;
+   }
+
+   /* Calculate the rate code */
+   rate = clk_get_rate(_refclk);
+   rate /= 1000;   /* To KHz */
+   for (i = 0; i < ARRAY_SIZE(dwc3_ti_am62_rate_table); i++) {
+   if (dwc3_ti_am62_rate_table[i] == rate)
+   break;
+   }
+
+   if (i == ARRAY_SIZE(dwc3_ti_am62_rate_table)) {
+   dev_err(dev, "unsupported usb2_refclk rate: %lu KHz\n", rate);
+   return;
+   }
+
+   rate_code = i;
+
+   /* Read the syscon property */
+   syscon = syscon_regmap_lookup_by_phandle(dev, 
"ti,syscon-phy-pll-refclk");
+   if (IS_ERR(syscon)) {
+   dev_err(dev, "unable to get ti,syscon-phy-pll-refclk regmap\n");
+   return;
+   }
+
+   ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), 
"ti,syscon-phy-pll-refclk", NULL, 1,
+0, );
+   if (ret)
+   return;
+
+   /* Program PHY PLL refclk by reading syscon property */
+   ret = regmap_update_bits(syscon, args.args[0], PHY_PLL_REFCLK_MASK, 
rate_code);
+   if (ret) {
+   dev_err(dev, "failed to set phy pll reference 

[PATCH v5 0/6] Add DFU and usb boot for TI am62x SK and beagleplay

2024-05-06 Thread Martyn Welch
This series adds DFU support for TI AM62 SK and beagleplay boards.

I have picked this series up from Sjoerd due to time constraints.

Since the last revision:
* Removed dwc3 mode setting in favour of reinstating forced peripheral
  mode for usb0
* Use of config fragments for both r5 and a53 DFU configuration to
  reduce duplication
* Typographical improvements to documentation

We plan to also submit the dts changes to linux so that those can be
dropped again in the near future (hopefully)

Changes in v5:
- Forcing usb0 into peripheral mode reinstated
- Switch to config fragment for a53 DFU configuration
- Use existing config fragment for a53 DFU configuration
- Typographical corrections

Changes in v4:
- Add config dependency on SYSCON
- Move defines and constants outside out of function scope
- Don't force usb0 into peripheral mode
- Move R5 dfu config to a config fragment rather then a full defconfig
- Don't enable XHCI for the R5 SPL, unneeded

Change in v3:
- Add dfu via environment rather then config headers
- Enable usb nodes in all boot phases
- Run savedefconfig to adjust to more recent u-boot

Changes in v2:
- Switch dwc3 glue to a seperate driver rather then in dwc-generic
- Minimize config changes to just DFU configuration
- Only enable usb port 0 DFU in SPL
- Create a seperate defconfig for R5

Sjoerd Simons (6):
  usb: dwc3: Add dwc3 glue driver for am62
  board: ti: am62x: am62x: include env for DFU
  arm: dts: k3-am625-sk: Enable usb port in u-boot
  configs: am62x_evm_*: Enable USB and DFU support
  beagleplay: Add DFU support
  doc: board: Add document for DFU boot on am62x SoCs

 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi |   9 ++
 arch/arm/dts/k3-am625-sk-u-boot.dtsi |   9 ++
 board/beagle/beagleplay/beagleplay.env   |   1 +
 board/ti/am62x/am62x.env |   1 +
 configs/am62x_a53_usbdfu.config  |  29 +
 configs/am62x_beagleplay_a53_defconfig   |   2 +
 configs/am62x_evm_a53_defconfig  |   3 +
 configs/am62x_r5_usbdfu.config   |  28 +
 doc/board/beagle/am62x_beagleplay.rst|  14 ++-
 doc/board/ti/am62x_sk.rst|  37 ++
 drivers/usb/dwc3/Kconfig |  14 +++
 drivers/usb/dwc3/Makefile|   1 +
 drivers/usb/dwc3/dwc3-am62.c | 125 +++
 13 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 configs/am62x_a53_usbdfu.config
 create mode 100644 configs/am62x_r5_usbdfu.config
 create mode 100644 drivers/usb/dwc3/dwc3-am62.c

-- 
2.43.0



Re: [PATCH] fs: ubifs: Add support for ZSTD decompression

2024-05-06 Thread Heiko Schocher

Hello Piotr,

On 30.04.24 12:23, Piotr Wojtaszczyk wrote:

Signed-off-by: Piotr Wojtaszczyk 
---

  fs/ubifs/ubifs-media.h |  2 ++
  fs/ubifs/ubifs.c   | 55 --
  2 files changed, 55 insertions(+), 2 deletions(-)


Looks good to me, thanks!

Acked-by: Heiko Schocher 

bye,
Heiko

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


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

2024-05-06 Thread Heiko Schocher

Hello Alexey,

On 06.05.24 15:58, Alexey Romanov wrote:

Hello! Ping.


okay from my side... I think I acked them already

@Dario: IIRC the patchset is delegated to you...

If it is okay, I can apply it in u-boot-ubi and send a pull request to
Tom, but please, send a Acked-by or Reviewed-by and delegate it back to me!

Thanks!

bye,
Heiko


On Mon, Mar 25, 2024 at 05:41:42PM +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].

---

Changes V1 -> V2 [2]:

  - Rebased over mtdblock v2 patchset [3].
  - Compile UBI partitions support only if CONFIG_BLK option
is enabled.

- Links:

   [1] 
https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
   [2] 
https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
   [3] 
https://lore.kernel.org/all/20240307130726.1582487-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 |   8 ++-
  drivers/mtd/ubi/Makefile|   1 +
  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, 332 insertions(+), 17 deletions(-)
  create mode 100644 drivers/mtd/ubi/block.c
  create mode 100644 drivers/mtd/ubi/part.c

--
2.34.1





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


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

2024-05-06 Thread Michael Nazzareno Trimarchi
Hi Alexey

Sorry will will put on CI

Michael

On Mon, May 6, 2024 at 3:58 PM Alexey Romanov
 wrote:
>
> Hello! Ping.
>
> On Mon, Mar 25, 2024 at 05:41:42PM +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].
> >
> > ---
> >
> > Changes V1 -> V2 [2]:
> >
> >  - Rebased over mtdblock v2 patchset [3].
> >  - Compile UBI partitions support only if CONFIG_BLK option
> >is enabled.
> >
> > - Links:
> >
> >   [1] 
> > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
> >   [2] 
> > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
> >   [3] 
> > https://lore.kernel.org/all/20240307130726.1582487-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 |   8 ++-
> >  drivers/mtd/ubi/Makefile|   1 +
> >  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, 332 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



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

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


[PATCH 1/1] arm: dts: k3-j7200: Move to OF_UPSTREAM

2024-05-06 Thread Aniket Limaye
Move to using OF_UPSTREAM config and thus using the devicetree-rebasing
subtree.

Signed-off-by: Aniket Limaye 
---
 arch/arm/dts/Makefile |1 -
 .../k3-j7200-common-proc-board-u-boot.dtsi|   16 +-
 arch/arm/dts/k3-j7200-common-proc-board.dts   |  396 -
 arch/arm/dts/k3-j7200-main.dtsi   | 1284 -
 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi |  647 -
 arch/arm/dts/k3-j7200-som-p0.dtsi |  327 -
 arch/arm/dts/k3-j7200-thermal.dtsi|   47 -
 arch/arm/dts/k3-j7200.dtsi|  164 ---
 configs/j7200_evm_a72_defconfig   |3 +-
 9 files changed, 8 insertions(+), 2877 deletions(-)
 delete mode 100644 arch/arm/dts/k3-j7200-common-proc-board.dts
 delete mode 100644 arch/arm/dts/k3-j7200-main.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-som-p0.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 592e7e05dd6..ec7dabbd174 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1321,7 +1321,6 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo
 dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-r5-common-proc-board.dtb \
- k3-j7200-common-proc-board.dtb \
  k3-j7200-r5-common-proc-board.dtb \
  k3-j721e-r5-sk.dtb \
  k3-j721e-beagleboneai64.dtb \
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index fdd9d1afb5b..15b6f0c63a5 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -3,7 +3,7 @@
  * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
  */
 
-#define SPL_BOARD_DTB "spl/dts/k3-j7200-common-proc-board.dtb"
+#define SPL_BOARD_DTB "spl/dts/ti/k3-j7200-common-proc-board.dtb"
 #define BOARD_DESCRIPTION "k3-j7200-common-proc-board"
 #define UBOOT_BOARD_DESCRIPTION "U-Boot for J7200 EVM"
 
@@ -30,8 +30,12 @@
 _mcu_wakeup {
bootph-all;
 
-   chipid@4314 {
+   wkup_conf: bus@4300 {
bootph-all;
+
+chipid: chipid@14 {
+bootph-all;
+};
};
 };
 
@@ -44,14 +48,6 @@
 };
 
 _udmap {
-   reg = <0x0 0x285c 0x0 0x100>,
-   <0x0 0x284c 0x0 0x4000>,
-   <0x0 0x2a80 0x0 0x4>,
-   <0x0 0x284a 0x0 0x4000>,
-   <0x0 0x2aa0 0x0 0x4>,
-   <0x0 0x2840 0x0 0x2000>;
-   reg-names = "gcfg", "rchan", "rchanrt", "tchan",
-   "tchanrt", "rflow";
bootph-all;
 };
 
diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-common-proc-board.dts
deleted file mode 100644
index cee2b4b0eb8..000
--- a/arch/arm/dts/k3-j7200-common-proc-board.dts
+++ /dev/null
@@ -1,396 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/dts-v1/;
-
-#include "k3-j7200-som-p0.dtsi"
-#include 
-#include 
-#include 
-
-#include "k3-serdes.h"
-
-/ {
-   compatible = "ti,j7200-evm", "ti,j7200";
-   model = "Texas Instruments J7200 EVM";
-
-   aliases {
-   serial0 = _uart0;
-   serial1 = _uart0;
-   serial2 = _uart0;
-   serial3 = _uart1;
-   serial5 = _uart3;
-   mmc0 = _sdhci0;
-   mmc1 = _sdhci1;
-   };
-
-   chosen {
-   stdout-path = "serial2:115200n8";
-   };
-
-   evm_12v0: fixedregulator-evm12v0 {
-   /* main supply */
-   compatible = "regulator-fixed";
-   regulator-name = "evm_12v0";
-   regulator-min-microvolt = <1200>;
-   regulator-max-microvolt = <1200>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-
-   vsys_3v3: fixedregulator-vsys3v3 {
-   /* Output of LM5140 */
-   compatible = "regulator-fixed";
-   regulator-name = "vsys_3v3";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   vin-supply = <_12v0>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-
-   vsys_5v0: fixedregulator-vsys5v0 {
-   /* Output of LM5140 */
-   compatible = "regulator-fixed";
-   regulator-name = "vsys_5v0";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   vin-supply = <_12v0>;
-   

[PATCH 0/1] Move j7200-evm to OF_UPSTREAM

2024-05-06 Thread Aniket Limaye
This patch moves the J7200 config to use the devicetree-rebasing subtree, and 
consequently makes
the necessary updates to the u-boot devicetree.

This patch depends on series [1] which cleans up k3 binman with some templating.

[1]: https://lore.kernel.org/u-boot/20240322131011.1029620-1-n-fran...@ti.com/

Boot logs:
https://gist.github.com/aniket-l/5ae460224307ed7bf47f20488e1d3457


Aniket Limaye (1):
  arm: dts: k3-j7200: Move to OF_UPSTREAM

 arch/arm/dts/Makefile |1 -
 .../k3-j7200-common-proc-board-u-boot.dtsi|   16 +-
 arch/arm/dts/k3-j7200-common-proc-board.dts   |  396 -
 arch/arm/dts/k3-j7200-main.dtsi   | 1284 -
 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi |  647 -
 arch/arm/dts/k3-j7200-som-p0.dtsi |  327 -
 arch/arm/dts/k3-j7200-thermal.dtsi|   47 -
 arch/arm/dts/k3-j7200.dtsi|  164 ---
 configs/j7200_evm_a72_defconfig   |3 +-
 9 files changed, 8 insertions(+), 2877 deletions(-)
 delete mode 100644 arch/arm/dts/k3-j7200-common-proc-board.dts
 delete mode 100644 arch/arm/dts/k3-j7200-main.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-som-p0.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
 delete mode 100644 arch/arm/dts/k3-j7200.dtsi

-- 
2.34.1



Re: [PATCH] board: rockchip: add ArmSoM Sige7 Rk3588 board

2024-05-06 Thread Jianfeng Liu
Hi Quentin,

Many thanks to your review.

On May 6, 2024, 8:54 a.m. UTC, Quentin Schulz wrote:
>>   F: arch/arm/include/asm/arch-rockchip/
>>   F: arch/arm/mach-rockchip/
>>   F: board/amarula/vyasa-rk3288/
>> +F: board/armsom/sige7-rk3588/
>
>Can you order this alphabetically please?

Sure, I will fix it.

>> + {
>> +   cap-mmc-highspeed;
>
>I think this isn't supported in U-Boot on RK35xx devices just yet? We
>force everything to be HS200+ anyway if I remember correctly.

I use the same devicetree as rock5b[1] and I haven't encountered issues.
I also remember kernel driver has issues with mmc-hs400, which will cause
system unstable, but it seems that this is fine in u-boot.

[1]
https://github.com/u-boot/u-boot/blob/bcaf6c0570deb7dcd3c029d2e74efea740a0b20a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi#L34

>I would recommend using
>arch/arm/dts/rk3588-armsom-sige7* here instead, as to not have to
>maintain a list of DTSes (e.g. if overlays are supported one day?)

Sure, I will change it.

>The wiki doesn't seem to indicate there's any SPI flash on that device
>so I don't think we need to support anything related to it, especially
>the creation of the image to flash on an SPI nor?

Yes there is no spi flash on board. I will delete those SPI flash related
configs.

>> +CONFIG_USB_HOST_ETHER=y
>> +CONFIG_USB_ETHER_ASIX=y
>> +CONFIG_USB_ETHER_ASIX88179=y
>> +CONFIG_USB_ETHER_LAN75XX=y
>> +CONFIG_USB_ETHER_LAN78XX=y
>> +CONFIG_USB_ETHER_MCS7830=y
>> +CONFIG_USB_ETHER_RTL8152=y
>> +CONFIG_USB_ETHER_SMSC95XX=y
>
>I'm surprised to see USB_ETHER support here? Is this something done on
>purpose? The board already has two 2.5Gbps Ethernet, are they not working?

I copied these configs from rock5b. I guess someone should have the need
to do net boot through usb ethernet since there is also usb support.

Best regards,
Jianfeng

Quentin Schulz  于2024年5月6日周一 16:54写道:

> Hi Jianfeng Liu,
>
> On 5/4/24 7:05 PM, Jianfeng Liu wrote:
> > [You don't often get email from liujianfeng1...@gmail.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > ArmSoM Sige7 is a Rockchip RK3588 based SBC (Single Board Computer) by
> > ArmSoM.
> >
> > There are two variants depending on the DRAM size : 8G and 16G.
> >
> > Specification:
> >
> >  Rockchip Rk3588 SoC
> >  4x ARM Cortex-A76, 4x ARM Cortex-A55
> >  8/16GB memory LPDDR4x
> >  Mali G610MC4 GPU
> >  2x MIPI CSI 2 multiple lanes connector
> >  64GB/128GB on board eMMC
> >  uSD slot
> >  1x USB 2.0 Type-A, 1x USB 3.0 Type-A, 1x USB 3.0 Type-C
> >  1x HDMI 2.1 output
> >  2x 2.5 Gbps Ethernet port
> >  40-pin IO header including UART, SPI and I2C
> >  USB PD over USB Type-C
> >  Size: 92mm x 62mm
> >
> > Kernel commit:
> > 81c828a67c78 (arm64: dts: rockchip: Add ArmSom Sige7 board)
> >
> > Note that these commits:
> > - e18e5e8188f2 (arm64: dts: rockchip: add USBDP phys on rk3588)
> > - 6fca4edb93d3 (arm64: dts: rockchip: Add rk3588 GPU node)
> > are not synced to u-boot, so I remove usb3 drd nodes and gpu from kernel
> > devicetree.
> >
> > Signed-off-by: Jianfeng Liu 
> > ---
> >
> >   MAINTAINERS  |   1 +
> >   arch/arm/dts/Makefile|   1 +
> >   arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi |  31 +
> >   arch/arm/dts/rk3588-armsom-sige7.dts | 691 +++
> >   arch/arm/mach-rockchip/rk3588/Kconfig|  26 +
> >   board/armsom/sige7-rk3588/Kconfig|  12 +
> >   board/armsom/sige7-rk3588/MAINTAINERS|   8 +
> >   configs/sige7-rk3588_defconfig   | 104 +++
> >   doc/board/rockchip/rockchip.rst  |   1 +
> >   include/configs/sige7-rk3588.h   |  15 +
> >   10 files changed, 890 insertions(+)
> >   create mode 100644 arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi
> >   create mode 100644 arch/arm/dts/rk3588-armsom-sige7.dts
> >   create mode 100644 board/armsom/sige7-rk3588/Kconfig
> >   create mode 100644 board/armsom/sige7-rk3588/MAINTAINERS
> >   create mode 100644 configs/sige7-rk3588_defconfig
> >   create mode 100644 include/configs/sige7-rk3588.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7a3b4d3712..52367bf38c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -532,6 +532,7 @@ F:  arch/arm/dts/rv11*
> >   F: arch/arm/include/asm/arch-rockchip/
> >   F: arch/arm/mach-rockchip/
> >   F: board/amarula/vyasa-rk3288/
> > +F: board/armsom/sige7-rk3588/
>
> Can you order this alphabetically please?
>
> >   F: board/anbernic/rgxx3_rk3566/
> >   F: board/chipspark/popmetal_rk3288
> >   F: board/engicam/px30_core/
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index c9f1b25ad6..040238dede 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -166,6 +166,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> >  rk3568-rock-3a.dtb
> >
> >   dtb-$(CONFIG_ROCKCHIP_RK3588) 

Re: [PATCH v2 1/4] binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing

2024-05-06 Thread Francesco Dolcini
Hello Marek,

On Fri, May 03, 2024 at 03:05:09AM +0200, Marek Vasut wrote:
> Add new binman etype which allows signing both the SPL and fitImage sections
> of i.MX8M flash.bin using CST. There are multiple DT properties which govern
> the signing process, nxp,loader-address is the only mandatory one which sets
> the SPL signature start address without the imx8mimage header, this should be
> SPL text base. The key material can be configured using optional DT properties
> nxp,srk-table, nxp,csf-crt, nxp,img-crt, all of which default the key material
> names generated by CST tool scripts. The nxp,unlock property can be used to
> unlock CAAM access in SPL section.
> 
> Signed-off-by: Marek Vasut 

I was not able to test or really look into your series [1], however I can
relate with a comment from Tim Harvey.

I think is important to keep in mind that that signing cannot be done
with key material that is in-tree, because well, that's private, and I
think we should not force people to branch to properly sign the
binaries.

I think that it would be valuable to share how do you foresee this used
in a real environment.

Francesco

[1] so feel free to reference me to any already agreed discussion on the
topic ...




Re: [PATCH v2 03/22] clk: rockchip: rk3399: Improve support for SCLK_PCIEPHY_REF clock

2024-05-06 Thread Quentin Schulz

Hi Jonas,

On 5/1/24 6:22 PM, Jonas Karlman wrote:

rk3399-nanopi-4.dtsi try to set parent of and set rate to 100 MHz of the
SCLK_PCIEPHY_REF clock.

The existing enable/disable ops for SCLK_PCIEPHY_REF currently force
use of 24 MHz parent and rate.

Add improved support for setting parent and rate of the pciephy refclk
to driver to better support assign-clock props for pciephy refclk in DT.

This limited implementation only support setting 24 or 100 MHz rate,
and expect npll and clk_pciephy_ref100m divider to use default values.

Signed-off-by: Jonas Karlman 
---
v2: Implement partial instead of dummy support for SCLK_PCIEPHY_REF
---
  drivers/clk/rockchip/clk_rk3399.c | 59 +--
  1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 5934771b4096..0b3223611a32 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -926,6 +926,26 @@ static ulong rk3399_saradc_set_clk(struct rockchip_cru 
*cru, uint hz)
return rk3399_saradc_get_clk(cru);
  }
  
+static ulong rk3399_pciephy_get_clk(struct rockchip_cru *cru)

+{
+   if (readl(>clksel_con[18]) & BIT(10))
+   return 100 * MHz;
+   else
+   return OSC_HZ;


Could avoid the else since all if blocks return, no other logic than the 
one matching the else can reach that part of the code.


Therefore:

"""
if (readl(>clksel_con[18]) & BIT(10))
return 100 * MHz;

return OSC_HZ;
"""

works just as well.

Could also be

"""
return (readl(>clksel_con[18]) & BIT(10)) ? 100 * MHz : OSC_HZ;
"""

[...]

+static int __maybe_unused rk3399_pciephy_set_parent(struct clk *clk,
+   struct clk *parent)
+{
+   struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
+   const char *clock_output_name;
+   int ret;
+
+   if (parent->dev == clk->dev && parent->id == SCLK_PCIEPHY_REF100M) {
+   rk_setreg(>cru->clksel_con[18], BIT(10));
+   return 0;
+   }
+
+   ret = dev_read_string_index(parent->dev, "clock-output-names",
+   parent->id, _output_name);


Are you sure this works?

Considering that parent->id seems to store unique ids, like 167 for 
SCLK_PCIEPHY_REF100M, I doubt we should be using it for 
dev_read_string_index


As per documentation:

"""
/**
 * dev_read_string_index() - obtain an indexed string from a string list
 *
 * @dev: device to examine
 * @propname: name of the property containing the string list
 * @index: index of the string to return
 * @outp: return location for the string
 *
 * Return:
 *   length of string, if found or -ve error value if not found
 */
int dev_read_string_index(const struct udevice *dev, const char *propname,
  int index, const char **outp);
"""

So index here means the (index+1)'th string in the list of strings under 
the "propname" DT property, I doubt we have properties with 167+ strings 
in them?


I realize that rk3399_gmac_set_parent also uses this, so I'm a bit 
puzzled right now...


Don't you want to use

dev_read_stringlist_search(parent->dev, "clock-output-names", "xin24m")

instead?

The rest looks good to me.

Cheers,
Quentin


Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards

2024-05-06 Thread Benjamin Hahn
Hi Fabio,

On 03.05.24 14:44, Fabio Estevam wrote:
> Hi Benjamin,
>
> On Fri, May 3, 2024 at 4:01 AM Benjamin Hahn  wrote:
>
>> -CONFIG_USB_GADGET_MANUFACTURER="FSL"
>> +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC"
>>   CONFIG_USB_GADGET_VENDOR_NUM=0x0525
>>   CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
> ...
>> -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
>> +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC"
>>   CONFIG_USB_GADGET_VENDOR_NUM=0x0451
>>   CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
> What about making VENDOR_NUM/PRODUCT_NUM consistent as well?

We are not registered at USB-IF and therefore don't have a valid 
VENDOR_NUM and PRODUCT_NUM, so we rely on the VENDOR_NUM and PRODUCT_NUM 
of the SoC Vendor, so the correct features get enabled by the driver.

With kind regards,

Benjamin Hahn



Re: [PATCH v2 18/18] rockchip: rk3399: Configure sdmmc regulator pinctrl in SPL

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

A few boards have shown to be required to properly configure pinctrl
for the fixed regulator gpio pin used by sdmmc before being able to read
from SD-cards.

Include the related gpio, regulator and pinctrl nodes and enable related
Kconfig options so that pinctrl can be configured in SPL for boards that
may be affected by such issue.

Also change to imply SPL_DM_SEQ_ALIAS for all boards because it must be
enabled for working gpio usage in SPL after a future DT sync.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
---
  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi  | 12 
  arch/arm/dts/rk3399-orangepi-u-boot.dtsi | 12 
  arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 12 
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi   | 12 
  arch/arm/dts/rk3399-rockpro64-u-boot.dtsi| 12 
  arch/arm/mach-rockchip/Kconfig   |  1 +
  configs/chromebook_bob_defconfig |  1 -
  configs/chromebook_kevin_defconfig   |  1 -
  configs/nanopc-t4-rk3399_defconfig   |  2 ++
  configs/nanopi-m4-2gb-rk3399_defconfig   |  2 ++
  configs/nanopi-m4-rk3399_defconfig   |  2 ++
  configs/nanopi-m4b-rk3399_defconfig  |  2 ++
  configs/nanopi-neo4-rk3399_defconfig |  2 ++
  configs/nanopi-r4s-rk3399_defconfig  |  2 ++
  configs/orangepi-rk3399_defconfig|  2 ++
  configs/pinebook-pro-rk3399_defconfig|  3 ++-
  configs/pinephone-pro-rk3399_defconfig   |  1 -
  configs/puma-rk3399_defconfig|  1 -
  configs/roc-pc-mezzanine-rk3399_defconfig|  2 +-
  configs/roc-pc-rk3399_defconfig  |  2 +-
  configs/rock-pi-4-rk3399_defconfig   |  1 -
  configs/rockpro64-rk3399_defconfig   |  3 ++-
  22 files changed, 81 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi 
b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
index a126bbaf086f..e0d7a518dfc2 100644
--- a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -5,6 +5,18 @@
  
  #include "rk3399-u-boot.dtsi"
  
+ {

+   bootph-pre-ram;
+};
+
   {
pinctrl-0 = <_bus4 _clk _cmd _cd>;
  };
+
+_pwr_h {
+   bootph-pre-ram;
+};
+
+_sd {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi 
b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
index d4327ea607c4..b7452eca2254 100644
--- a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
@@ -6,6 +6,18 @@
  #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-ddr3-1333.dtsi"
  
+ {

+   bootph-pre-ram;
+};
+
+_pwr_h {
+   bootph-pre-ram;
+};
+
+_sd {
+   bootph-pre-ram;
+};
+
  _log {
regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi 
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 17af95a114fc..2341db444ef3 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -10,6 +10,10 @@
rockchip,panel = <_panel>;
  };
  
+ {

+   bootph-pre-ram;
+};
+
   {
max-frequency = <2500>;
  };
@@ -18,11 +22,19 @@
max-frequency = <2000>;
  };
  
+_pwr_h_pin {

+   bootph-pre-ram;
+};
+
   {
bootph-pre-ram;
bootph-some-ram;
  };
  
+_sd {

+   bootph-pre-ram;
+};
+
  _log {
regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index d40daacc7823..aecf7dbe383c 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -32,6 +32,10 @@
vin-supply = <_vbus_typec0>;
  };
  
+ {

+   bootph-pre-ram;
+};
+
   {
flash@0 {
bootph-pre-ram;
@@ -39,6 +43,14 @@
};
  };
  
+_sd {

+   bootph-pre-ram;
+};
+
+_sd_en {
+   bootph-pre-ram;
+};
+
  _host {
regulator-always-on;
  };
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi 
b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index e280739057df..43b67991fe5a 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -28,11 +28,19 @@
  };
  };
  
+ {

+   bootph-pre-ram;
+};
+
   {
cap-mmc-highspeed;
mmc-ddr-1_8v;
  };
  
+_pwr_h {

+   bootph-pre-ram;
+};
+
   {
flash@0 {
bootph-pre-ram;
@@ -40,6 +48,10 @@
};
  };
  
+_sd {

+   bootph-pre-ram;
+};
+
  _center {
regulator-min-microvolt = <95>;
regulator-max-microvolt = <95>;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 7d6374b73586..262cb7cba3ea 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -277,6 +277,7 @@ config ROCKCHIP_RK3399

Re: [PATCH v2 17/18] rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

When RK3399 boards run SPL from eMMC and fail to load FIT from eMMC due
to it being missing or checksum validation fails there can be a fallback
to read FIT from SD-card. However, without proper pinctrl configuration
reading FIT from SD-card may fail:

   U-Boot SPL 2024.04-rc4 (Mar 17 2024 - 22:54:45 +)
   Trying to boot from MMC2
   mmc_load_image_raw_sector: mmc block read error
   Trying to boot from MMC2
   mmc_load_image_raw_sector: mmc block read error
   Trying to boot from MMC1
   Card did not respond to voltage select! : -110
   mmc_init: -95, time 12
   spl: mmc init failed with error: -95
   SPL: failed to boot from all boot devices (err=-6)
   ### ERROR ### Please RESET the board ###

Fix this by tagging related sdhci, sdmmc and spi flash pinctrl nodes
with bootph props. Also move bootph for common nodes shared by all
boards to the SoC u-boot.dtsi.

eMMC, SD-Card and SPI flash nodes are also changed to only be tagged
with bootph props for SPL and U-Boot pre-reloc phases.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Split patch, only keep sdhci, sdmmc and spi1 bootph/pinctrl changes
 in this patch
v2: Also include sdhci, sdmmc and spi1 nodes at pre-reloc phase
v2: Update commit message
---
  arch/arm/dts/rk3399-ficus-u-boot.dtsi| 10 
  arch/arm/dts/rk3399-gru-u-boot.dtsi  | 24 +
  arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi |  3 +-
  arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi  | 23 +---
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi   |  5 +-
  arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi | 10 
  arch/arm/dts/rk3399-rock960-u-boot.dtsi  | 10 
  arch/arm/dts/rk3399-rockpro64-u-boot.dtsi|  7 ++-
  arch/arm/dts/rk3399-u-boot.dtsi  | 57 ++--
  configs/eaidk-610-rk3399_defconfig   |  2 +-
  configs/evb-rk3399_defconfig |  2 +-
  configs/ficus-rk3399_defconfig   |  2 +-
  configs/firefly-rk3399_defconfig |  2 +-
  configs/khadas-edge-captain-rk3399_defconfig |  2 +-
  configs/khadas-edge-rk3399_defconfig |  2 +-
  configs/khadas-edge-v-rk3399_defconfig   |  2 +-
  configs/leez-rk3399_defconfig|  2 +-
  configs/nanopc-t4-rk3399_defconfig   |  2 +-
  configs/nanopi-m4-2gb-rk3399_defconfig   |  2 +-
  configs/nanopi-m4-rk3399_defconfig   |  2 +-
  configs/nanopi-m4b-rk3399_defconfig  |  2 +-
  configs/nanopi-neo4-rk3399_defconfig |  2 +-
  configs/nanopi-r4s-rk3399_defconfig  |  2 +-
  configs/orangepi-rk3399_defconfig|  2 +-
  configs/pinebook-pro-rk3399_defconfig|  2 +-
  configs/pinephone-pro-rk3399_defconfig   |  2 +-
  configs/roc-pc-mezzanine-rk3399_defconfig|  2 +-
  configs/roc-pc-rk3399_defconfig  |  2 +-
  configs/rock-4c-plus-rk3399_defconfig|  2 +-
  configs/rock-4se-rk3399_defconfig|  2 +-
  configs/rock-pi-4-rk3399_defconfig   |  2 +-
  configs/rock-pi-4c-rk3399_defconfig  |  2 +-
  configs/rock-pi-n10-rk3399pro_defconfig  |  2 +-
  configs/rock960-rk3399_defconfig |  2 +-
  configs/rockpro64-rk3399_defconfig   |  2 +-
  35 files changed, 142 insertions(+), 59 deletions(-)

diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi 
b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
index 67b63a835238..ac924d6dc592 100644
--- a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
@@ -5,3 +5,13 @@
  
  #include "rk3399-u-boot.dtsi"

  #include "rk3399-sdram-ddr3-1600.dtsi"
+
+_pull_none_18ma {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+_pull_up_8ma {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi 
b/arch/arm/dts/rk3399-gru-u-boot.dtsi
index b1604a6872c0..0cc40eb6d6f6 100644
--- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
@@ -54,6 +54,30 @@
enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
  };
  
+ {

+   /delete-property/ bootph-pre-ram;
+};
+
+ {
+   /delete-property/ bootph-pre-ram;
+};
+
+_bus4 {
+   /delete-property/ bootph-pre-ram;
+};
+
+_cd {
+   /delete-property/ bootph-pre-ram;
+};
+
+_clk {
+   /delete-property/ bootph-pre-ram;
+};
+
+_cmd {
+   /delete-property/ bootph-pre-ram;
+};
+
   {
spi-activate-delay = <100>;
spi-max-frequency = <300>;
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi 
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 56fdaf440aea..17af95a114fc 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -19,7 +19,8 @@
  };
  
   {

-   bootph-all;
+   bootph-pre-ram;
+   bootph-some-ram;
  };
  
  _log {

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi 
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index d1912a2ef6a9..1930e5e10353 100644
--- 

Re: [PATCH v2 16/18] rockchip: rk3399: Include uart related pinctrl nodes in TPL/SPL

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

The initial serial console UART iomux is typically configured in
board_debug_uart_init() at TPL stage on Rockchip platform.

Later stages typically use pinctrl driver to configure iomux UART once
again based on the control FDT.

Include uart related pinctrl nodes in TPL/SPL control FDT to make it
possible for pinctrl driver to configure UART iomux at TPL/SPL stage.

Following debug log message may also be seen at U-Boot pre-reloc stage:

   ns16550_serial serial@ff1a: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

This can be resolved by including bootph prop for U-Bood pre-reloc
phase (bootph-some-ram or bootph-all). However, this has intentionally
been excluded due to including it unnecessarily slows down boot around
200-400 ms.

Also add the clock-frequency prop similar to what has been done for
other Rockchip SoCs.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
v2: Change to only include pinctrl nodes in TPL and SPL phase

Hopefully the clock-frequency prop can be used to help speed up boot in
a future patch series, loading the uart rate from clock driver currently
delays boot at i.e. U-Boot proper pre-reloc.
---
  arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 16 
  arch/arm/dts/rk3399-u-boot.dtsi |  6 ++
  2 files changed, 22 insertions(+)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi 
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 390cf24152a6..d1912a2ef6a9 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -113,4 +113,20 @@
  
   {

bootph-all;
+   clock-frequency = <2400>;
+};
+
+_cts {
+   bootph-pre-sram;
+   bootph-pre-ram;
+};
+
+_rts {
+   bootph-pre-sram;
+   bootph-pre-ram;
+};
+
+_xfer {
+   bootph-pre-sram;
+   bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 9815dc53e8ed..b39fe39fa2b3 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -136,6 +136,12 @@
  
   {

bootph-all;
+   clock-frequency = <2400>;
+};
+
+_xfer {
+   bootph-pre-sram;
+   bootph-pre-ram;
  };
  
   {


Re: [PATCH v2 15/18] rockchip: rk3399-puma: Move uart0 bootph to board u-boot.dtsi

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

rk3399-puma is the only supported board that use uart0 for serial
console, other RK3399 boards typically use uart2 for serial console
and may use uart0 for bluetooth.

Move setting bootph prop to board u-boot.dtsi to only include the uart0
node in TPL/SPL control FDT for the rk3399-puma target.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
---
  arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 4 
  arch/arm/dts/rk3399-u-boot.dtsi | 4 
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi 
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 2b3ea6da88db..390cf24152a6 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -110,3 +110,7 @@
  _cmd {
bootph-all;
  };
+
+ {
+   bootph-all;
+};
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 496f25d9fbf6..9815dc53e8ed 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -134,10 +134,6 @@
bootph-all;
  };
  
- {

-   bootph-all;
-};
-
   {
bootph-all;
  };


Re: [PATCH v2 14/18] rockchip: rk3399: Fix bootph prop for vop nodes

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

The vop nodes should not be included in TPL/SPL control FDT, it should
only be included at U-Boot proper pre-reloc phase.

Change to use bootph-some-ram prop to fix this.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
---
  arch/arm/dts/rk3399-u-boot.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index b9b8d3ee1d92..496f25d9fbf6 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -143,9 +143,9 @@
  };
  
   {

-   bootph-all;
+   bootph-some-ram;
  };
  
   {

-   bootph-all;
+   bootph-some-ram;
  };


Re: [PATCH v2 13/18] rockchip: rk3399: Sort nodes in u-boot.dtsi files

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

Sort nodes alphabetically by name, symbol or reg addr in RK3399 related
u-boot.dtsi files. Also remove one of the duplicated  nodes.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
---
  arch/arm/dts/rk3399-evb-u-boot.dtsi| 24 -
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 -
  arch/arm/dts/rk3399-u-boot.dtsi| 37 --
  3 files changed, 35 insertions(+), 38 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index 9df4a02c3e74..6dedfeec0722 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -20,6 +20,18 @@
bootph-all;
  };
  
+ {

+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   cd-gpios = < 7 GPIO_ACTIVE_LOW>;
+   disable-wp;
+   max-frequency = <15000>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _bus4>;
+   status = "okay";
+};
+
   {
status = "okay";
  };
@@ -36,15 +48,3 @@
  _center {
regulator-init-microvolt = <90>;
  };
-
- {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   cd-gpios = < 7 GPIO_ACTIVE_LOW>;
-   disable-wp;
-   max-frequency = <15000>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _bus4>;
-   status = "okay";
-};
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index e390cf3abab5..58a3c0afcddd 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -38,12 +38,11 @@
};
  };
  
-_log {

-   regulator-min-microvolt = <43>;
-   regulator-init-microvolt = <95>;
+_host {
+   regulator-always-on;
  };
  
-_host {

+_sdio {
regulator-always-on;
  };
  
@@ -51,6 +50,7 @@

regulator-always-on;
  };
  
-_sdio {

-   regulator-always-on;
+_log {
+   regulator-min-microvolt = <43>;
+   regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 96523a138ae3..b9b8d3ee1d92 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -18,19 +18,25 @@
u-boot,spl-boot-order = "same-as-spl", , 
};
  
-	cic: syscon@ff62 {

+   pmusgrf: syscon@ff33 {
+   compatible = "rockchip,rk3399-pmusgrf", "syscon";
+   reg = <0x0 0xff33 0x0 0xe3d4>;
bootph-all;
+   };
+
+   cic: syscon@ff62 {
compatible = "rockchip,rk3399-cic", "syscon";
reg = <0x0 0xff62 0x0 0x100>;
+   bootph-all;
};
  
  	dfi: dfi@ff63 {

-   bootph-all;
reg = <0x00 0xff63 0x00 0x4000>;
compatible = "rockchip,rk3399-dfi";
rockchip,pmu = <>;
clocks = < PCLK_DDR_MON>;
clock-names = "pclk_ddr_mon";
+   bootph-all;
};
  
  	rng: rng@ff8b8000 {

@@ -39,12 +45,7 @@
};
  
  	dmc: dmc {

-   bootph-all;
compatible = "rockchip,rk3399-dmc";
-   devfreq-events = <>;
-   interrupts = ;
-   clocks = < SCLK_DDRCLK>;
-   clock-names = "dmc_clk";
reg = <0x0 0xffa8 0x0 0x0800
   0x0 0xffa80800 0x0 0x1800
   0x0 0xffa82000 0x0 0x2000
@@ -53,14 +54,12 @@
   0x0 0xffa88800 0x0 0x1800
   0x0 0xffa8a000 0x0 0x2000
   0x0 0xffa8c000 0x0 0x1000>;
-   };
-
-   pmusgrf: syscon@ff33 {
+   devfreq-events = <>;
+   interrupts = ;
+   clocks = < SCLK_DDRCLK>;
+   clock-names = "dmc_clk";
bootph-all;
-   compatible = "rockchip,rk3399-pmusgrf", "syscon";
-   reg = <0x0 0xff33 0x0 0xe3d4>;
};
-
  };
  
  #if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)

@@ -108,21 +107,19 @@
bootph-all;
  };
  
- {

-   bootph-all;
-};
-
- {
+ {
bootph-all;
  };
  
- {

+ {
bootph-all;
  };
  
   {

-   max-frequency = <2>;
bootph-all;
+   max-frequency = <2>;
+
+   /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
u-boot,spl-fifo-mode;
  };
  


Re: [PATCH v2 12/18] rockchip: rk3399: Remove inherited bootph-all props

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

Remove superfluous bootph-all props already inherited from main soc
u-boot.dtsi file.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "Fix loading FIT from SD-card" patch
---
  arch/arm/dts/rk3399-evb-u-boot.dtsi   | 1 -
  arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi  | 2 --
  arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 2 --
  3 files changed, 5 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index 796ac9642399..9df4a02c3e74 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -38,7 +38,6 @@
  };
  
   {

-   bootph-all;
bus-width = <4>;
cap-mmc-highspeed;
cap-sd-highspeed;
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi 
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 83b0c44e9ec5..56fdaf440aea 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -12,12 +12,10 @@
  
   {

max-frequency = <2500>;
-   bootph-all;
  };
  
   {

max-frequency = <2000>;
-   bootph-all;
  };
  
   {

diff --git a/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi 
b/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
index 5dc7d0db5f73..dcfcec4f3072 100644
--- a/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
@@ -8,10 +8,8 @@
  
   {

max-frequency = <2500>;
-   bootph-all;
  };
  
   {

max-frequency = <2000>;
-   bootph-all;
  };


Re: [PATCH v2 11/18] rockchip: rk3399: Add a default spl-boot-order prop

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

A lot of RK3399 boards use a u-boot,spl-boot-order of "same-as-spl",
 and 

Move this to rk3399-u-boot.dtsi and make this default for boards
currently missing a u-boot,spl-boot-order prop.

Before commit a7e69952eb6d ("rockchip: spl: Cache boot source id for
later use") it was required to include the SPI flash node in the
u-boot,spl-boot-order prop to successfully load FIT from SPI flash.

The SPI flash node reference has been dropped from spl-boot-order from
pinebook-pro, roc-pc and rockpro64 now that "same-as-spl" also gets
resolved to the SPI flash node and loading FIT from SPI flash works
without having the node explicitly referenced in spl-boot-order prop.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Update commit message
---
  arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi  | 1 -
  arch/arm/dts/rk3399-evb-u-boot.dtsi| 1 -
  arch/arm/dts/rk3399-ficus-u-boot.dtsi  | 6 --
  arch/arm/dts/rk3399-firefly-u-boot.dtsi| 6 --
  arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi| 6 --
  arch/arm/dts/rk3399-leez-p710-u-boot.dtsi  | 6 --
  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi| 6 --
  arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi   | 6 --
  arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi  | 6 --
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 
  arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi  | 6 --
  arch/arm/dts/rk3399-rock960-u-boot.dtsi| 5 -
  arch/arm/dts/rk3399-rockpro64-u-boot.dtsi  | 5 +
  arch/arm/dts/rk3399-u-boot.dtsi| 4 
  arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi | 6 --
  15 files changed, 5 insertions(+), 69 deletions(-)

diff --git a/arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi 
b/arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi
index a3f27566e438..6c07de98fa01 100644
--- a/arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi
@@ -9,7 +9,6 @@
  / {
chosen {
stdout-path = "serial2:150n8";
-   u-boot,spl-boot-order = "same-as-spl", , 
};
  };
  
diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi b/arch/arm/dts/rk3399-evb-u-boot.dtsi

index dfce63e4d428..796ac9642399 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -9,7 +9,6 @@
  / {
chosen {
stdout-path = "serial2:150n8";
-   u-boot,spl-boot-order = "same-as-spl", , 
};
  };
  
diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi b/arch/arm/dts/rk3399-ficus-u-boot.dtsi

index 38e0897db91d..67b63a835238 100644
--- a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
@@ -5,9 +5,3 @@
  
  #include "rk3399-u-boot.dtsi"

  #include "rk3399-sdram-ddr3-1600.dtsi"
-
-/ {
-   chosen {
-   u-boot,spl-boot-order = "same-as-spl", , 
-   };
-};
diff --git a/arch/arm/dts/rk3399-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
index c58ad95d120a..1f5fda1d0f1d 100644
--- a/arch/arm/dts/rk3399-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
@@ -6,12 +6,6 @@
  #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-ddr3-1600.dtsi"
  
-/ {

-   chosen {
-   u-boot,spl-boot-order = "same-as-spl", , 
-   };
-};
-
  _log {
regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi 
b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
index a7039d74a016..4a3b23e48313 100644
--- a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
@@ -6,12 +6,6 @@
  #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-lpddr4-100.dtsi"
  
-/ {

-   chosen {
-   u-boot,spl-boot-order = "same-as-spl", , 
-   };
-};
-
  _log {
regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi 
b/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
index c638ce259731..03b596850635 100644
--- a/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
@@ -6,12 +6,6 @@
  #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-lpddr4-100.dtsi"
  
-/ {

-   chosen {
-   u-boot,spl-boot-order = "same-as-spl", , 
-   };
-};
-
  _log {
regulator-init-microvolt = <95>;
  };
diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi 
b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
index a9d10592d573..a126bbaf086f 100644
--- a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -5,12 +5,6 @@
  
  #include "rk3399-u-boot.dtsi"
  
-/{

-   chosen {
-   u-boot,spl-boot-order = "same-as-spl", , 
-   };
-};
-
   {
pinctrl-0 = <_bus4 _clk _cmd _cd>;
  };
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi 
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 88a77cad8d43..83b0c44e9ec5 100644
--- 

Re: [PATCH v2 06/18] rockchip: rk3399: Enable ARMv8 crypto and FIT checksum validation

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

The RK3399 SoC support the ARMv8 Cryptography Extensions, use of ARMv8
crypto can speed up FIT checksum validation in SPL.

Imply ARMV8_SET_SMPEN and ARMV8_CRYPTO to take advantage of the crypto
extensions for SHA256 when validating checksum of FIT images.

Imply SPL_FIT_SIGNATURE and LEGACY_IMAGE_FORMAT to enable FIT checksum
validation to almost all RK3399 boards.

The following boards have been excluded:
- chromebook_bob: SPL max size limitation of 120 KiB
- chromebook_kevin: SPL max size limitation of 120 KiB

Also imply OF_LIVE to help speed up init of U-Boot proper and disable
CONFIG_SPL_RAW_IMAGE_SUPPORT on leez-rk3399 to ensure SPL does not try
to jump to code that failed checksum validation.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Do not exclude puma-rk3399 from FIT checksum validation in SPL
---
  arch/arm/mach-rockchip/Kconfig | 5 +
  configs/chromebook_bob_defconfig   | 1 +
  configs/chromebook_kevin_defconfig | 1 +
  configs/leez-rk3399_defconfig  | 1 +
  configs/puma-rk3399_defconfig  | 1 -
  configs/rock-4se-rk3399_defconfig  | 2 --
  configs/rock-pi-4-rk3399_defconfig | 1 -
  configs/rockpro64-rk3399_defconfig | 2 --
  8 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 20f1b7572a31..7c0116da4921 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -261,15 +261,20 @@ config ROCKCHIP_RK3399
select DM_PMIC
select DM_REGULATOR_FIXED
select BOARD_LATE_INIT
+   imply ARMV8_CRYPTO
+   imply ARMV8_SET_SMPEN
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply LEGACY_IMAGE_FORMAT
imply MISC
imply MISC_INIT_R
+   imply OF_LIVE
imply PARTITION_TYPE_GUID
imply PRE_CONSOLE_BUFFER
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_EFUSE
imply ROCKCHIP_SDRAM_COMMON
+   imply SPL_FIT_SIGNATURE
imply SPL_ROCKCHIP_COMMON_BOARD
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply TPL_CLK
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index 805da11dbf6a..400b2d7ed7de 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
  CONFIG_SPL_SPI=y
  CONFIG_SYS_LOAD_ADDR=0x800800
  CONFIG_DEBUG_UART=y
+# CONFIG_SPL_FIT_SIGNATURE is not set
  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
  # CONFIG_DISPLAY_CPUINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 8744152df61d..a881028cc7eb 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -29,6 +29,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
  CONFIG_SPL_SPI=y
  CONFIG_SYS_LOAD_ADDR=0x800800
  CONFIG_DEBUG_UART=y
+# CONFIG_SPL_FIT_SIGNATURE is not set
  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
  # CONFIG_DISPLAY_CPUINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/leez-rk3399_defconfig b/configs/leez-rk3399_defconfig
index e5088341389a..2831cfb36689 100644
--- a/configs/leez-rk3399_defconfig
+++ b/configs/leez-rk3399_defconfig
@@ -15,6 +15,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-leez-p710.dtb"
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x2e000
  CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
  CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
  CONFIG_TPL=y
  CONFIG_CMD_BOOTZ=y
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index bd4926cf0fce..53fc62bf7e35 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -42,7 +42,6 @@ CONFIG_CMD_TIME=y
  CONFIG_CMD_PMIC=y
  CONFIG_CMD_REGULATOR=y
  CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIVE=y
  CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates 
assigned-clock-parents"
  CONFIG_ENV_OVERWRITE=y
  CONFIG_ENV_IS_IN_MMC=y
diff --git a/configs/rock-4se-rk3399_defconfig 
b/configs/rock-4se-rk3399_defconfig
index 712502517eb2..04622df3c0a0 100644
--- a/configs/rock-4se-rk3399_defconfig
+++ b/configs/rock-4se-rk3399_defconfig
@@ -15,8 +15,6 @@ CONFIG_SYS_LOAD_ADDR=0x800800
  CONFIG_PCI=y
  CONFIG_DEBUG_UART=y
  # CONFIG_ANDROID_BOOT_IMAGE is not set
-CONFIG_SPL_FIT_SIGNATURE=y
-CONFIG_LEGACY_IMAGE_FORMAT=y
  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-4se.dtb"
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x2e000
diff --git a/configs/rock-pi-4-rk3399_defconfig 
b/configs/rock-pi-4-rk3399_defconfig
index 315b8b853fc3..9036c51de421 100644
--- a/configs/rock-pi-4-rk3399_defconfig
+++ b/configs/rock-pi-4-rk3399_defconfig
@@ -19,7 +19,6 @@ CONFIG_SYS_LOAD_ADDR=0x800800
  CONFIG_PCI=y
  CONFIG_DEBUG_UART=y
  # CONFIG_ANDROID_BOOT_IMAGE is not set
-CONFIG_SPL_FIT_SIGNATURE=y
  

Re: [PATCH v2 03/18] rockchip: rk3399-puma: Use common bss and stack addresses

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

The rk3399-puma board is currently using SPL stack and bss addr in SRAM,
the same addr typically used by TPL, this differs from most other RK3399
boards.

Switch to use the common bss and stack addresses introduced in commit
008ba0d56d00 ("rockchip: Add common default bss and stack addresses").

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch
---
  configs/puma-rk3399_defconfig | 10 --
  1 file changed, 10 deletions(-)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index ec7d52a6e13e..bd4926cf0fce 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -2,11 +2,8 @@ CONFIG_ARM=y
  CONFIG_SKIP_LOWLEVEL_INIT=y
  CONFIG_COUNTER_FREQUENCY=2400
  CONFIG_ARCH_ROCKCHIP=y
-CONFIG_TEXT_BASE=0x0020
  CONFIG_SPL_GPIO=y
  CONFIG_NR_DRAM_BANKS=1
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_ENV_SIZE=0x3000
  CONFIG_ENV_OFFSET=0x3F8000
@@ -16,12 +13,6 @@ CONFIG_ROCKCHIP_RK3399=y
  CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0
  CONFIG_ROCKCHIP_SPI_IMAGE=y
  CONFIG_TARGET_PUMA_RK3399=y
-CONFIG_SPL_STACK=0xff8e
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0xff8e
-CONFIG_SPL_BSS_MAX_SIZE=0x1
-CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
  CONFIG_DEBUG_UART_BASE=0xFF18
  CONFIG_DEBUG_UART_CLOCK=2400
  CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -33,7 +24,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x2e000
  CONFIG_SPL_PAD_TO=0x38000
  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
-# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
  CONFIG_SPL_I2C=y
  CONFIG_SPL_POWER=y


Re: [PATCH v2 02/18] rockchip: rk3399-puma: Update SPL_PAD_TO Kconfig option

2024-05-06 Thread Kever Yang



On 2024/4/30 23:30, Jonas Karlman wrote:

On rk3399-puma the FIT payload is located at sector 0x200 compared
to the more Rockchip common sector 0x4000 offset:

   SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200

Because FIT payload is located at sector 0x200 and IDBlock is located at
sector 64, the combined size of TPL+SPL (idbloader.img) cannot take up
more than 224 KiB:

   (0x200 - 64) x 512 = 0x38000 (224 KiB)

Adjust SPL_PAD_TO to match the used 0x200 sector offset.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from DT sync patch

With this change it should be possible to drop the following u-boot.dtsi
override and use the default offset = .

   offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
---
  configs/puma-rk3399_defconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 14a7bc8b1e00..ec7d52a6e13e 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -31,7 +31,7 @@ CONFIG_DEBUG_UART=y
  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
  CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_SPL_MAX_SIZE=0x2e000
-CONFIG_SPL_PAD_TO=0x7f8000
+CONFIG_SPL_PAD_TO=0x38000
  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200


Re: [PATCH v2 03/22] clk: rockchip: rk3399: Improve support for SCLK_PCIEPHY_REF clock

2024-05-06 Thread Kever Yang



On 2024/5/2 00:22, Jonas Karlman wrote:

rk3399-nanopi-4.dtsi try to set parent of and set rate to 100 MHz of the
SCLK_PCIEPHY_REF clock.

The existing enable/disable ops for SCLK_PCIEPHY_REF currently force
use of 24 MHz parent and rate.

Add improved support for setting parent and rate of the pciephy refclk
to driver to better support assign-clock props for pciephy refclk in DT.

This limited implementation only support setting 24 or 100 MHz rate,
and expect npll and clk_pciephy_ref100m divider to use default values.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Implement partial instead of dummy support for SCLK_PCIEPHY_REF
---
  drivers/clk/rockchip/clk_rk3399.c | 59 +--
  1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 5934771b4096..0b3223611a32 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -926,6 +926,26 @@ static ulong rk3399_saradc_set_clk(struct rockchip_cru 
*cru, uint hz)
return rk3399_saradc_get_clk(cru);
  }
  
+static ulong rk3399_pciephy_get_clk(struct rockchip_cru *cru)

+{
+   if (readl(>clksel_con[18]) & BIT(10))
+   return 100 * MHz;
+   else
+   return OSC_HZ;
+}
+
+static ulong rk3399_pciephy_set_clk(struct rockchip_cru *cru, uint hz)
+{
+   if (hz == 100 * MHz)
+   rk_setreg(>clksel_con[18], BIT(10));
+   else if (hz == OSC_HZ)
+   rk_clrreg(>clksel_con[18], BIT(10));
+   else
+   return -EINVAL;
+
+   return rk3399_pciephy_get_clk(cru);
+}
+
  static ulong rk3399_clk_get_rate(struct clk *clk)
  {
struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
@@ -967,6 +987,9 @@ static ulong rk3399_clk_get_rate(struct clk *clk)
case SCLK_SARADC:
rate = rk3399_saradc_get_clk(priv->cru);
break;
+   case SCLK_PCIEPHY_REF:
+   rate = rk3399_pciephy_get_clk(priv->cru);
+   break;
case ACLK_VIO:
case ACLK_HDCP:
case ACLK_GIC_PRE:
@@ -1058,6 +1081,9 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_SARADC:
ret = rk3399_saradc_set_clk(priv->cru, rate);
break;
+   case SCLK_PCIEPHY_REF:
+   ret = rk3399_pciephy_set_clk(priv->cru, rate);
+   break;
case ACLK_VIO:
case ACLK_HDCP:
case ACLK_GIC_PRE:
@@ -1108,12 +1134,39 @@ static int __maybe_unused rk3399_gmac_set_parent(struct 
clk *clk,
return -EINVAL;
  }
  
+static int __maybe_unused rk3399_pciephy_set_parent(struct clk *clk,

+   struct clk *parent)
+{
+   struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
+   const char *clock_output_name;
+   int ret;
+
+   if (parent->dev == clk->dev && parent->id == SCLK_PCIEPHY_REF100M) {
+   rk_setreg(>cru->clksel_con[18], BIT(10));
+   return 0;
+   }
+
+   ret = dev_read_string_index(parent->dev, "clock-output-names",
+   parent->id, _output_name);
+   if (ret < 0)
+   return -ENODATA;
+
+   if (!strcmp(clock_output_name, "xin24m")) {
+   rk_clrreg(>cru->clksel_con[18], BIT(10));
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
  static int __maybe_unused rk3399_clk_set_parent(struct clk *clk,
struct clk *parent)
  {
switch (clk->id) {
case SCLK_RMII_SRC:
return rk3399_gmac_set_parent(clk, parent);
+   case SCLK_PCIEPHY_REF:
+   return rk3399_pciephy_set_parent(clk, parent);
}
  
  	debug("%s: unsupported clk %ld\n", __func__, clk->id);

@@ -1204,7 +1257,8 @@ static int rk3399_clk_enable(struct clk *clk)
rk_clrreg(>cru->clkgate_con[13], BIT(7));
break;
case SCLK_PCIEPHY_REF:
-   rk_clrreg(>cru->clksel_con[18], BIT(10));
+   if (readl(>cru->clksel_con[18]) & BIT(10))
+   rk_clrreg(>cru->clkgate_con[12], BIT(6));
break;
default:
debug("%s: unsupported clk %ld\n", __func__, clk->id);
@@ -1298,7 +1352,8 @@ static int rk3399_clk_disable(struct clk *clk)
rk_setreg(>cru->clkgate_con[13], BIT(7));
break;
case SCLK_PCIEPHY_REF:
-   rk_clrreg(>cru->clksel_con[18], BIT(10));
+   if (readl(>cru->clksel_con[18]) & BIT(10))
+   rk_setreg(>cru->clkgate_con[12], BIT(6));
break;
default:
debug("%s: unsupported clk %ld\n", __func__, clk->id);


[PATCH v2 2/2] ehci: msm: bring up iface + core clocks

2024-05-06 Thread Sam Day
This seems to be necessary on my samsung-a5. Without this patch, the
first access of EHCI registers causes a bus stall and subsequent reset.

I am unsure why this wasn't already necessary for db410c, perhaps those
clocks are already enabled on boot.

Reviewed-by: Caleb Connolly 
Signed-off-by: Sam Day 
---
 drivers/usb/host/ehci-msm.c | 37 +++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 98fe7bc3bc..b2e294dd64 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -7,8 +7,10 @@
  * Based on Linux driver
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +27,8 @@ struct msm_ehci_priv {
struct usb_ehci *ehci; /* Start of IP core*/
struct ulpi_viewport ulpi_vp; /* ULPI Viewport */
struct phy phy;
+   struct clk iface_clk;
+   struct clk core_clk;
 };
 
 static int msm_init_after_reset(struct ehci_ctrl *dev)
@@ -53,20 +57,46 @@ static int ehci_usb_probe(struct udevice *dev)
struct ehci_hcor *hcor;
int ret;
 
+   ret = clk_get_by_name(dev, "core", >core_clk);
+   if (ret) {
+   dev_err(dev, "Failed to get core clock: %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_get_by_name(dev, "iface", >iface_clk);
+   if (ret) {
+   dev_err(dev, "Failed to get iface clock: %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(>core_clk);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(>iface_clk);
+   if (ret)
+   goto cleanup_core;
+
hccr = (struct ehci_hccr *)((phys_addr_t)>caplength);
hcor = (struct ehci_hcor *)((phys_addr_t)hccr +
HC_LENGTH(ehci_readl(&(hccr)->cr_capbase)));
 
ret = generic_setup_phy(dev, >phy, 0);
if (ret)
-   return ret;
+   goto cleanup_iface;
 
ret = board_usb_init(0, plat->init_type);
if (ret < 0)
-   return ret;
+   goto cleanup_iface;
 
return ehci_register(dev, hccr, hcor, _ehci_ops, 0,
 plat->init_type);
+
+cleanup_iface:
+   clk_disable_unprepare(>iface_clk);
+cleanup_core:
+   clk_disable_unprepare(>core_clk);
+   return ret;
 }
 
 static int ehci_usb_remove(struct udevice *dev)
@@ -82,6 +112,9 @@ static int ehci_usb_remove(struct udevice *dev)
/* Stop controller. */
clrbits_le32(>usbcmd, CMD_RUN);
 
+   clk_disable_unprepare(>iface_clk);
+   clk_disable_unprepare(>core_clk);
+
ret = generic_shutdown_phy(>phy);
if (ret)
return ret;

-- 
2.44.0




[PATCH v2 1/2] clk/qcom: apq8016: add support for USB_HS clocks

2024-05-06 Thread Sam Day
The newer "register map for simple gate clocks" support added for qcom
clocks is used. As a result gcc_apq8016 now has a mixture of the old and
new styles. I didn't (and still don't!) feel comfortable enough in this
area to update the existing code.

Signed-off-by: Sam Day 
---
 drivers/clk/qcom/clock-apq8016.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index d3b63b9c1a..3b8c88c769 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -17,6 +17,8 @@
 
 #include "clock-qcom.h"
 
+#define USB_HS_SYSTEM_CLK_CMD_RCGR 0x41010
+
 /* Clocks: (from CLK_CTL_BASE)  */
 #define GPLL0_STATUS   (0x2101C)
 #define APCS_GPLL_ENA_VOTE (0x45000)
@@ -52,6 +54,11 @@ static struct vote_clk gcc_blsp1_ahb_clk = {
.vote_bit = BIT(10),
 };
 
+static const struct gate_clk apq8016_clks[] = {
+   GATE_CLK(GCC_USB_HS_AHB_CLK,0x41008, 0x0001),
+   GATE_CLK(GCC_USB_HS_SYSTEM_CLK, 0x41004, 0x0001),
+};
+
 /* SDHCI */
 static int apq8016_clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
 {
@@ -117,13 +124,38 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong 
rate)
case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
apq8016_clk_init_uart(priv->base, clk->id);
return 7372800;
+   case GCC_USB_HS_SYSTEM_CLK:
+   if (rate != 8000)
+   log_warning("Unexpected rate %ld requested for 
USB_HS_SYSTEM_CLK\n",
+   rate);
+   clk_rcg_set_rate_mnd(priv->base, USB_HS_SYSTEM_CLK_CMD_RCGR,
+10, 0, 0, CFG_CLK_SRC_GPLL0, 0);
+   return rate;
default:
return 0;
}
 }
 
+static int apq8016_clk_enable(struct clk *clk)
+{
+   struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+
+   if (priv->data->num_clks < clk->id) {
+   log_warning("%s: unknown clk id %lu\n", __func__, clk->id);
+   return 0;
+   }
+
+   debug("%s: clk %s\n", __func__, apq8016_clks[clk->id].name);
+   qcom_gate_clk_en(priv, clk->id);
+
+   return 0;
+}
+
 static struct msm_clk_data apq8016_clk_data = {
.set_rate = apq8016_clk_set_rate,
+   .clks = apq8016_clks,
+   .num_clks = ARRAY_SIZE(apq8016_clks),
+   .enable = apq8016_clk_enable,
 };
 
 static const struct udevice_id gcc_apq8016_of_match[] = {

-- 
2.44.0




[PATCH v2 0/2] qcom: ehci: enable core + iface clocks

2024-05-06 Thread Sam Day
These clocks are mandatory, as can be seen in msm_hsusb driver in the
Linux kernel.

The appropriate HS_USB AHB/SYSTEM clocks were added to gcc_apq8016.

Technically there's other adjacent SoC families that can use the
msm_hsusb driver with different clocks, but only msm8916/apq8016 are
currently making use of it so I think this change shouldn't break
anything elsewhere.

Signed-off-by: Sam Day 
---
Changes in v2:
- Remove nonsensical/unnecessary reference to pending qcom debug dump
  from commit message.
- Collapse ftbl_gcc_usb_hs_system_clk into apq8016_clk_set_rate, since
  it's only 1 entry.
- Add bounds check on clock id in apq8016_clk_enable
- Add warn if a rate other than 80mhz is requested for
  GCC_USB_HS_SYSTEM_CLK
- Caleb: I opted to keep the non-bulk clock enablement code as-is in
  ehci_msm, since that more closely resembles the existing Linux
  kernel code.
- Link to v1: 
https://lore.kernel.org/r/20240502-msm8916-hs-usb-clocks-v1-0-eeccf483b...@samcday.com

---
Sam Day (2):
  clk/qcom: apq8016: add support for USB_HS clocks
  ehci: msm: bring up iface + core clocks

 drivers/clk/qcom/clock-apq8016.c | 32 
 drivers/usb/host/ehci-msm.c  | 37 +++--
 2 files changed, 67 insertions(+), 2 deletions(-)
---
base-commit: 2f1e76bcfee75b9f99ade63002c05ffaaec86afb
change-id: 20240502-msm8916-hs-usb-clocks-34bc22b03f3d

Best regards,
-- 
Sam Day 




Re: [PATCH u-boot-mvebu 10/10] arm: mvebu: turris_omnia: Support old DDR3 training, selectable via env var

2024-05-06 Thread Stefan Roese

Hi Marek,

On 4/15/24 18:30, Marek Behún wrote:

Support old DDR3 training code on Turris Omnia, selectable by U-Boot
enviroment variable.

Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting the
environment variable
   env set omnia_ddr3_training old
   env save

Signed-off-by: Marek Behún 
---
  arch/arm/mach-mvebu/Kconfig   |  1 +
  board/CZ.NIC/turris_omnia/Makefile|  1 +
  board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 +++
  board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 +-
  4 files changed, 82 insertions(+), 1 deletion(-)
  create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c


For turris_omnia_defconfig, this is dropped when compiled:

drivers/ddr/marvell/a38x/old/ddr3_debug.c:776:12: warning: 
'ddr3_tip_access_atr' declared 'static' but never defined 
[-Wunused-function]
  776 | static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, u32 
value, u32 **ptr);

  |^~~

Please take a look.

Thanks,
Stefan


diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index e377e8a48a..4a8328760e 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -149,6 +149,7 @@ config TARGET_TURRIS_OMNIA
select SPL_SYS_MALLOC_SIMPLE
select SYS_I2C_MVTWSI
select ATSHA204A
+   select ARMADA_38X_SUPPORT_OLD_DDR3_TRAINING
  
  config TARGET_TURRIS_MOX

bool "Support CZ.NIC's Turris Mox / RIPE Atlas Probe"
diff --git a/board/CZ.NIC/turris_omnia/Makefile 
b/board/CZ.NIC/turris_omnia/Makefile
index 341378b4e5..28142cca7e 100644
--- a/board/CZ.NIC/turris_omnia/Makefile
+++ b/board/CZ.NIC/turris_omnia/Makefile
@@ -3,3 +3,4 @@
  # Copyright (C) 2017 Marek Behún 
  
  obj-y	:= turris_omnia.o ../turris_atsha_otp.o ../turris_common.o

+obj-$(CONFIG_SPL_BUILD)+= old_ddr3_training.o
diff --git a/board/CZ.NIC/turris_omnia/old_ddr3_training.c 
b/board/CZ.NIC/turris_omnia/old_ddr3_training.c
new file mode 100644
index 00..f7e89c58d4
--- /dev/null
+++ b/board/CZ.NIC/turris_omnia/old_ddr3_training.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 Marek Behún 
+ */
+
+#include 
+#include 
+#include 
+
+#include "../drivers/ddr/marvell/a38x/old/ddr3_init.h"
+
+static struct hws_topology_map board_topology_map_1g = {
+   0x1, /* active interfaces */
+   /* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
+   { { { {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0} },
+   SPEED_BIN_DDR_1600K,/* speed_bin */
+   BUS_WIDTH_16,   /* memory_width */
+   MEM_4G, /* mem_size */
+   DDR_FREQ_800,   /* frequency */
+   0, 0,   /* cas_l cas_wl */
+   HWS_TEMP_NORMAL,/* temperature */
+   HWS_TIM_2T} },  /* timing (force 2t) */
+   5,  /* Num Of Bus Per Interface*/
+   BUS_MASK_32BIT  /* Busses mask */
+};
+
+static struct hws_topology_map board_topology_map_2g = {
+   0x1, /* active interfaces */
+   /* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
+   { { { {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0},
+ {0x1, 0, 0, 0} },
+   SPEED_BIN_DDR_1600K,/* speed_bin */
+   BUS_WIDTH_16,   /* memory_width */
+   MEM_8G, /* mem_size */
+   DDR_FREQ_800,   /* frequency */
+   0, 0,   /* cas_l cas_wl */
+   HWS_TEMP_NORMAL,/* temperature */
+   HWS_TIM_2T} },  /* timing (force 2t) */
+   5,  /* Num Of Bus Per Interface*/
+   BUS_MASK_32BIT  /* Busses mask */
+};
+
+/* defined in turris_omnia.c */
+extern int omnia_get_ram_size_gb(void);
+
+struct hws_topology_map *ddr3_get_topology_map(void)
+{
+   if (omnia_get_ram_size_gb() == 2)
+   return _topology_map_2g;
+   else
+   return _topology_map_1g;
+}
+
+bool board_use_old_ddr3_training(void)
+{
+   const char *env_val = NULL;
+
+   if (CONFIG_IS_ENABLED(ENV_SUPPORT) && !env_init())
+   env_val = env_get("omnia_ddr3_training");
+
+   if (env_val && !strcmp(env_val, "old")) {
+   printf("Using old DDR3 training implementation\n");
+   return true;
+   }
+
+   return false;
+}
+
+__weak u32 sys_env_get_topology_update_info(struct topology_update_info *tui)
+{
+   return MV_OK;
+}
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 

[PATCH 1/1] riscv: add NULL check before calling strlen in the riscv cpu's get_desc()

2024-05-06 Thread Hanyuan Zhao
Without the NULL check, if the devicetree that u-boot loads does not have a
compatible property then a store access fault will be raised and force the
machine to reset, due to the NULL pointer we passed to strlen. This commit
adds this check and will return -ENOSPC to indicate the get_desc failed.

Signed-off-by: Hanyuan Zhao 
---
 drivers/cpu/riscv_cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 9b1950efe0..d39a943cb8 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -24,7 +24,7 @@ static int riscv_cpu_get_desc(const struct udevice *dev, char 
*buf, int size)
const char *cpu;
 
cpu = dev_read_string(dev, "compatible");
-   if (size < (strlen(cpu) + 1))
+   if (!cpu || size < (strlen(cpu) + 1))
return -ENOSPC;
 
strcpy(buf, cpu);
-- 
2.34.1



Re: [PATCH] board: rockchip: add ArmSoM Sige7 Rk3588 board

2024-05-06 Thread Quentin Schulz

Hi Jianfeng Liu,

On 5/4/24 7:05 PM, Jianfeng Liu wrote:

[You don't often get email from liujianfeng1...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

ArmSoM Sige7 is a Rockchip RK3588 based SBC (Single Board Computer) by
ArmSoM.

There are two variants depending on the DRAM size : 8G and 16G.

Specification:

 Rockchip Rk3588 SoC
 4x ARM Cortex-A76, 4x ARM Cortex-A55
 8/16GB memory LPDDR4x
 Mali G610MC4 GPU
 2x MIPI CSI 2 multiple lanes connector
 64GB/128GB on board eMMC
 uSD slot
 1x USB 2.0 Type-A, 1x USB 3.0 Type-A, 1x USB 3.0 Type-C
 1x HDMI 2.1 output
 2x 2.5 Gbps Ethernet port
 40-pin IO header including UART, SPI and I2C
 USB PD over USB Type-C
 Size: 92mm x 62mm

Kernel commit:
81c828a67c78 (arm64: dts: rockchip: Add ArmSom Sige7 board)

Note that these commits:
- e18e5e8188f2 (arm64: dts: rockchip: add USBDP phys on rk3588)
- 6fca4edb93d3 (arm64: dts: rockchip: Add rk3588 GPU node)
are not synced to u-boot, so I remove usb3 drd nodes and gpu from kernel
devicetree.

Signed-off-by: Jianfeng Liu 
---

  MAINTAINERS  |   1 +
  arch/arm/dts/Makefile|   1 +
  arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi |  31 +
  arch/arm/dts/rk3588-armsom-sige7.dts | 691 +++
  arch/arm/mach-rockchip/rk3588/Kconfig|  26 +
  board/armsom/sige7-rk3588/Kconfig|  12 +
  board/armsom/sige7-rk3588/MAINTAINERS|   8 +
  configs/sige7-rk3588_defconfig   | 104 +++
  doc/board/rockchip/rockchip.rst  |   1 +
  include/configs/sige7-rk3588.h   |  15 +
  10 files changed, 890 insertions(+)
  create mode 100644 arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3588-armsom-sige7.dts
  create mode 100644 board/armsom/sige7-rk3588/Kconfig
  create mode 100644 board/armsom/sige7-rk3588/MAINTAINERS
  create mode 100644 configs/sige7-rk3588_defconfig
  create mode 100644 include/configs/sige7-rk3588.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a3b4d3712..52367bf38c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -532,6 +532,7 @@ F:  arch/arm/dts/rv11*
  F: arch/arm/include/asm/arch-rockchip/
  F: arch/arm/mach-rockchip/
  F: board/amarula/vyasa-rk3288/
+F: board/armsom/sige7-rk3588/


Can you order this alphabetically please?


  F: board/anbernic/rgxx3_rk3566/
  F: board/chipspark/popmetal_rk3288
  F: board/engicam/px30_core/
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c9f1b25ad6..040238dede 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
 rk3568-rock-3a.dtb

  dtb-$(CONFIG_ROCKCHIP_RK3588) += \
+   rk3588-armsom-sige7.dtb \
 rk3588s-coolpi-4b.dtb \
 rk3588-coolpi-cm5-evb.dtb \
 rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi 
b/arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi
new file mode 100644
index 00..b9196ba5f5
--- /dev/null
+++ b/arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 ArmSoM Technology Co., Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+ {
+   cap-mmc-highspeed;


I think this isn't supported in U-Boot on RK35xx devices just yet? We 
force everything to be HS200+ anyway if I remember correctly.



+   mmc-hs200-1_8v;
+};
+
+ {
+   status = "okay";
+};
+
+_otg {
+   status = "okay";
+};
+
+_phy1 {
+   status = "okay";
+};
+
+_phy1_u3 {
+   status = "okay";
+};
+
+_host1_xhci {
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-armsom-sige7.dts 
b/arch/arm/dts/rk3588-armsom-sige7.dts
new file mode 100644
index 00..c7b46536ec
--- /dev/null
+++ b/arch/arm/dts/rk3588-armsom-sige7.dts
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   model = "ArmSoM Sige7";
+   compatible = "armsom,sige7", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   analog-sound {
+   compatible = "audio-graph-card";
+   dais = <_8ch_p0>;
+   label = "rk3588-es8316";
+   hp-det-gpio = < RK_PD5 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_detect>;
+   routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+   widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = 

Re: [EXTERNAL] Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read

2024-05-06 Thread Michael Nazzareno Trimarchi
Hi Ravi

On Tue, Apr 30, 2024 at 6:25 AM Ravi Minnikanti  wrote:
>
> On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote:
>
> > --
> > On Mon, Apr 29, 2024 at 6:22 PM Chris Packham  
> > wrote:
> >>
> >> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti  
> >> wrote:
> >>>
> >>> Once a page is read with higher bitflips all subsequent reads
> >>> are returning the same bitflip value even though they have none.
> >>> max_bitflip variable is not being reset to 0 across page reads.
> >>>
> >>> This is causing problems like incorrectly
> >>> marking erase blocks bad by UBI and causing read failures.
> >>>
> >>> Verified the change with both MTD reads and UBI.
> >>> This change is inline with other NFC drivers.
> >>>
> >>> Sample error log where a block is marked bad incorrectly:
> >>>
> >>> ubi0: fixable bit-flip detected at PEB 125
> >>> ubi0: run torture test for PEB 125
> >>> ubi0: fixable bit-flip detected at PEB 125
> >>> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> >>> must be bad
> >>> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> >>> ubi0: mark PEB 125 as bad
> >>>
> >>> Signed-off-by: rminnikanti 
> >>
> >> Looks good to me
> >>
> >> Reviewed-by: Chris Packham 
> >>
> >>> ---
> >>>  drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c 
> >>> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> index 1d9a6d107b..d2a4faad56 100644
> >>> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> >>> @@ -800,6 +800,11 @@ static void prepare_start_command(struct 
> >>> pxa3xx_nand_info *info, int command)
> >>> info->ecc_err_cnt   = 0;
> >>> info->ndcb3 = 0;
> >>> info->need_wait = 0;
> >>> +   /*
> >>> +* Reset max_bitflips to zero. Once command is complete,
> >>> +* max_bitflips for this READ is returned in ecc.read_page()
> >>> +*/
> >>> +   info->max_bitflips  = 0;
> >>>
> >
> > Why this should not be put to 0 in read_page instead on 
> > prepare_start_command?
> >
> > Michael
> >
>
> ecc.read_page is invoked after the read command execution.
> First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page is 
> invoked
> to read the page from buffer. So, by the time read_page is invoked, 
> info->max_bitflips
> must already have the bit flip value.
>

All the other implementation has a slight different way to handle.
>From what you said the reset should
be done on for NAND_CMD_READ0 command and should be sufficient.
Technically should be moved
in switch and not unconditionally.

Michael

> Thanks, Ravi.
>
> >>> switch (command) {
> >>> case NAND_CMD_READ0:
> >>> --
> >>> 2.17.1
> >
>


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

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


Re: [PATCH 080/149] board: kontron: Remove and add needed includes

2024-05-06 Thread Frieder Schrempf
On 01.05.24 04:42, Tom Rini wrote:
> Remove  from this board vendor directory and when needed
> add missing include files directly.
> 
> Signed-off-by: Tom Rini 

Acked-by: Frieder Schrempf