[PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM

2024-01-19 Thread Marek Vasut
Linux 6.6.y with KASLR enabled would print the following message on boot:
"
KASLR disabled due to lack of seed
"
Enable the 'kaslrseed' command so a random number seed can be pulled
from CAAM and inserted into the /chosen node 'kaslr-seed' property of
Linux kernel DT before boot, thus letting KASLR work properly.

Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Stefano Babic 
Cc: u-b...@dh-electronics.com
---
 configs/imx8mp_dhcom_pdk2_defconfig | 2 ++
 configs/imx8mp_dhcom_pdk3_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/imx8mp_dhcom_pdk2_defconfig 
b/configs/imx8mp_dhcom_pdk2_defconfig
index 4f907ce00d0..23fb6272ad5 100644
--- a/configs/imx8mp_dhcom_pdk2_defconfig
+++ b/configs/imx8mp_dhcom_pdk2_defconfig
@@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
 CONFIG_CMD_SYSBOOT=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
@@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
 CONFIG_SPL_DM_REGULATOR_PCA9450=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_CONS_INDEX=2
diff --git a/configs/imx8mp_dhcom_pdk3_defconfig 
b/configs/imx8mp_dhcom_pdk3_defconfig
index 9972e2d96b6..0d47c12b1f9 100644
--- a/configs/imx8mp_dhcom_pdk3_defconfig
+++ b/configs/imx8mp_dhcom_pdk3_defconfig
@@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
 CONFIG_CMD_SYSBOOT=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
@@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
 CONFIG_SPL_DM_REGULATOR_PCA9450=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_CONS_INDEX=2
-- 
2.43.0



Re: [PATCH 1/1] riscv: Support building with Clang

2024-01-19 Thread Tom Rini
On Sat, Jan 20, 2024 at 01:14:04AM +0100, kleines Filmröllchen wrote:

> The -ffixed-gp option of GCC has an exact equivalent of -ffixed-x3 in
> Clang.
> 
> Signed-off-by: kleines Filmröllchen 
> ---
> 
>  arch/riscv/config.mk | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
> index 9cf2aef0a4..dc4f30d673 100644
> --- a/arch/riscv/config.mk
> +++ b/arch/riscv/config.mk
> @@ -9,6 +9,9 @@
>  # Copyright (C) 2017 Andes Technology Corporation
>  # Rick Chen, Andes Technology Corporation 
>  #
> +# Copyright (C) 2024 the SerenityOS project
> +# kleines Filmröllchen 
> +#
>  
>  32bit-emul   := elf32lriscv
>  64bit-emul   := elf64lriscv

We don't have hard and fast rules about adding copyright lines, but this
seems a bit excessive.

> @@ -25,7 +28,12 @@ EFI_LDS:= elf_riscv64_efi.lds
>  PLATFORM_ELFFLAGS+= -B riscv -O elf64-littleriscv
>  endif
>  
> -PLATFORM_CPPFLAGS+= -ffixed-gp -fpic
> +PLATFORM_CPPFLAGS+= -fpic
> +ifeq ($(cc-name),clang)
> +PLATFORM_CPPFLAGS   += -ffixed-x3
> +else
> +PLATFORM_CPPFLAGS   += -ffixed-gp
> +endif
>  PLATFORM_RELFLAGS+= -fno-common -ffunction-sections -fdata-sections
>  LDFLAGS_u-boot   += --gc-sections -static -pie

A quick check shows that GCC support -ffixed-x3 as well, so we should
just use that in all cases.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 1/1] riscv: Support building with Clang

2024-01-19 Thread kleines Filmröllchen
The -ffixed-gp option of GCC has an exact equivalent of -ffixed-x3 in
Clang.

Signed-off-by: kleines Filmröllchen 
---

 arch/riscv/config.mk | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
index 9cf2aef0a4..dc4f30d673 100644
--- a/arch/riscv/config.mk
+++ b/arch/riscv/config.mk
@@ -9,6 +9,9 @@
 # Copyright (C) 2017 Andes Technology Corporation
 # Rick Chen, Andes Technology Corporation 
 #
+# Copyright (C) 2024 the SerenityOS project
+# kleines Filmröllchen 
+#
 
 32bit-emul := elf32lriscv
 64bit-emul := elf64lriscv
@@ -25,7 +28,12 @@ EFI_LDS  := elf_riscv64_efi.lds
 PLATFORM_ELFFLAGS  += -B riscv -O elf64-littleriscv
 endif
 
-PLATFORM_CPPFLAGS  += -ffixed-gp -fpic
+PLATFORM_CPPFLAGS  += -fpic
+ifeq ($(cc-name),clang)
+PLATFORM_CPPFLAGS   += -ffixed-x3
+else
+PLATFORM_CPPFLAGS   += -ffixed-gp
+endif
 PLATFORM_RELFLAGS  += -fno-common -ffunction-sections -fdata-sections
 LDFLAGS_u-boot += --gc-sections -static -pie
 
-- 
2.39.2


[PATCH 0/1] riscv: Support building with Clang

2024-01-19 Thread kleines Filmröllchen


Hello everyone!

This is a minimal patchset for making U-Boot build with Clang on RISC-V,
something I stumbled upon while writing U-Boot build scripts for
SerenityOS's RISC-V port. The only change is a (for unclear reasons...)
differently-named flag for fixing the global pointer.

Notably, this patch does not make U-Boot actually functional under
Clang. Booting this on QEMU (`-M virt -kernel path/to/u-boot -serial
stdio`) hangs after the image is loaded. I do not have the motivation to
debug this, but it may be helpful for further work on getting a working
build out of Clang on this architecture.

Greetings,
kleines Filmröllchen

PS: I am new to a mail patch contribution workflow and may have messed
this up despite reading through plenty relevant documentation. Please
kindly point out any improvements I could make on my side.


kleines Filmröllchen (1):
  riscv: Support building with Clang

 arch/riscv/config.mk | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.39.2


Re: [PATCH v1] net: sun8i-emac: Add support for fixed-link phy

2024-01-19 Thread Andre Przywara
On Fri, 19 Jan 2024 21:11:07 +0300
Maxim Kiselev  wrote:

Hi Maxim,

> пт, 19 янв. 2024 г. в 20:35, Andre Przywara :
> >
> > On Tue, 16 Jan 2024 19:58:56 +0300
> > Maxim Kiselev  wrote:
> >
> > Hi Maxim,
> >  
> > > вт, 16 янв. 2024 г. в 03:18, Andre Przywara :  
> > > >
> > > > On Thu, 15 Jun 2023 00:44:06 +0300
> > > > Maxim Kiselev  wrote:
> > > >
> > > > Hi Maxim,
> > > >  
> > > > > From: Maksim Kiselev 
> > > > >
> > > > > Based on dt-specs fixed-link doesn't require phy-handle to be used.  
> > > >
> > > > Do you have such a board?  
> > >
> > > Yes, I had a custom board with T113 SoC which has fixed phy eth.  
> >
> > So just to clarify: this board connected something like a switch directly
> > to the MAC, just using RMII/RGMII? And then you have a fixed-phy node in
> > the DT, detailing the speed and duplex parameters? Matching the fixed-phy
> > node description in ethernet-controller.yaml? And drivers/net/phy/fixed.c
> > takes care of parsing that?  
> 
> Yes, you are absolutely right. The T113s connected directly to the switch port
> via RMII interface. Here is the part of DT, that describes that configuration

Excellent, thanks for the confirmation!

Looking forward to v2!

Cheers,
Andre

>  {
>pinctrl-names = "default";
>pinctrl-0 = <_pg_pins>;
>phy-mode = "rmii";
>snps,reset-gpio = < 4 12 GPIO_ACTIVE_LOW>; /* PE12 */
>allwinner,tx-delay-ps = <700>;
>allwinner,rx-delay-ps = <3100>;
> 
>fixed-link {
>speed = <100>;
>full-duplex;
>};
> };
> 
> >  
> > > > And where is that written down? I don't see
> > > > it explicitly mentioned as optional in ethernet-controller.yaml or in
> > > > the DT spec PDF.  
> > >
> > > Sorry for that commit description. I just found the similar commit, that
> > > fixes the same problem for zynq_gem
> > > 3888c8d1979289efe685fe29276aed4d4b685975 ("net: zynq_gem: Add support for
> > > fixed-link phy") and copied the description from there.
> > >  
> > > > The sun8i EMAC binding lists phy-handle as required,
> > > > so that would need to be relaxed there then.  
> > >
> > > Oh, indeed. So it will require to send dt-binding changes to Linux 
> > > first...
> > >
> > > Therefore, I think we can live without fixed-phy support for sun8i EMAC.
> > > At least until some device with such a configuration appears on the
> > > market :)  
> >
> > Well, I am fine with that patch if it fixes a problem for you. It looks
> > like requiring the phy-handle property is too strict, and just needs to be
> > relaxed in the binding. If I see this correctly, the driver would still
> > accept every valid DT, by today's and future bindings?
> >
> > If you could just confirm my above assumptions, and maybe send a v2 with an
> > amended commit message, I would be happy to merge that patch.  
> 
> Sure, I'll fix the commit description and send v2 asap.
> 
> > Cheers,
> > Andre
> >  
> > > > > Fix driver to only read phy related setting when phy-handle is found. 
> > > > >  
> > > >
> > > > The patch itself looks fine, we already specify -1 as the default when
> > > > the PHY DT node does not contain a reg property, so that looks like it
> > > > would work.
> > > >
> > > > Cheers,
> > > > Andre
> > > >  
> > > > > Signed-off-by: Maksim Kiselev 
> > > > > ---
> > > > >  drivers/net/sun8i_emac.c | 7 ++-
> > > > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > > > index 04c3274fbe..0e339d69e0 100644
> > > > > --- a/drivers/net/sun8i_emac.c
> > > > > +++ b/drivers/net/sun8i_emac.c
> > > > > @@ -834,11 +834,8 @@ static int sun8i_emac_eth_of_to_plat(struct 
> > > > > udevice *dev)
> > > > >   priv->use_internal_phy = false;
> > > > >
> > > > >   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, 
> > > > > "phy-handle");
> > > > > - if (offset < 0) {
> > > > > - debug("%s: Cannot find PHY address\n", __func__);
> > > > > - return -EINVAL;
> > > > > - }
> > > > > - priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
> > > > > + if (offset >= 0)
> > > > > + priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, 
> > > > > "reg", -1);
> > > > >
> > > > >   pdata->phy_interface = dev_read_phy_mode(dev);
> > > > >   debug("phy interface %d\n", pdata->phy_interface);  
> > > >  
> > >
> > > Best wishes,
> > > Maksim  
> >  
> 
> Best wishes,
> Maksim



[PATCH] env: sf: report malloc error to caller

2024-01-19 Thread Ralph Siemsen
In the non-redundant code for env_sf_save(), a failure to malloc() the
temporary buffer produces the following output:

Saving Environment to SPIFlash... OK

This is misleading as the flash has neither been erased nor written.

Fix it to return an error to the caller, so the output will be:

Saving Environment to SPIFlash... Failed (-12)

Note that there is another copy of env_sf_save() in the same file, for
handling redundant environment, and it already has the same logic.

Signed-off-by: Ralph Siemsen 
---
 env/sf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/env/sf.c b/env/sf.c
index a425ecc11c8..8f5c03b00d3 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -210,8 +210,10 @@ static int env_sf_save(void)
saved_size = sect_size - CONFIG_ENV_SIZE;
saved_offset = CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE;
saved_buffer = malloc(saved_size);
-   if (!saved_buffer)
+   if (!saved_buffer) {
+   ret = -ENOMEM;
goto done;
+   }
 
ret = spi_flash_read(env_flash, saved_offset,
saved_size, saved_buffer);
-- 
2.25.1



Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Jens Maus
Hi,

> Am 19.01.2024 um 17:53 schrieb Jens Maus :
> 
>> Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov :
>> 
>>> So you say with your own u-boot.bin you see serial U-Boot output after that 
>>> „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the 
>>> UART on the GPIO header?
>>> 
>> 
>> Yes :-) See attached log file.
> 
> Really strange that in your case U-Boot seems to come up nicely and outputs 
> something on the debug UART. Here definitely not. And the only difference in 
> the rpi boot loader log outputs I could spot between yours and mine is:

Replying to myself after having analysed this a bit further this evening...

> […]
> 
> So lets see if after you updated to a more recent rpi eeprom U-boot is still 
> able to boot…

I actually do have some good and bad news:

1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on 
the HDMI and on the serial debug UART like you reported.

2. Bad news: I actually got it working by downgrading the rpi-eeprom to the 
same 2023/10/30 (VERSION:30de0ba5) version like you have.

So the issue I saw/reported seems to be somehow related/limited to newer 
rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log 
output differences, the potentially relevant piece might be the "M.2 PCIe HAT 
not detected.“ line that is only present in newer rpi-eeprom version outputs.

So hopefully you can reproduce that issue yourself when upgrading your 
rpi-eeprom version to newer or also the latest version from 2024/01/15 
available [1] and potentially find the actual piece that prevent your patchset 
from working on newer eeprom versions.

Best regards,
jens

[1] https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/



[PATCH] pico-dwarf/hobbit-imx6ul: Convert to CONFIG_DM_SERIAL

2024-01-19 Thread Fabio Estevam
The conversion to CONFIG_DM_SERIAL is mandatory, so select
this option.

Signed-off-by: Fabio Estevam 
---
 configs/pico-dwarf-imx6ul_defconfig  | 1 +
 configs/pico-hobbit-imx6ul_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/pico-dwarf-imx6ul_defconfig 
b/configs/pico-dwarf-imx6ul_defconfig
index 7ae37264612c..8b90285980f4 100644
--- a/configs/pico-dwarf-imx6ul_defconfig
+++ b/configs/pico-dwarf-imx6ul_defconfig
@@ -67,6 +67,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_USB=y
 CONFIG_SPL_USB_HOST=y
diff --git a/configs/pico-hobbit-imx6ul_defconfig 
b/configs/pico-hobbit-imx6ul_defconfig
index fc5a54b4e5ed..e3aca6e82e16 100644
--- a/configs/pico-hobbit-imx6ul_defconfig
+++ b/configs/pico-hobbit-imx6ul_defconfig
@@ -70,6 +70,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_USB=y
 CONFIG_SPL_USB_HOST=y
-- 
2.34.1



Re: [PATCH v8 09/16] board: ti: j784s4: Add board support for J784S4 EVM

2024-01-19 Thread Nishanth Menon
On 23:20-20240119, Apurva Nandan wrote:
> Add board files for J784S4 EVM.
> 
> SYS_DISABLE_DCACHE_OPS is selected in the Kconfig because
> J784S4/AM69 are a coherent architecture at A72 level by
> MSMC support.
> 
> Signed-off-by: Hari Nagalla 
> [ add env and board specific yaml files for binman ]
Neither of them are part of this patch?
> Signed-off-by: Neha Malcom Francis 
> [ cleaned up the env files ]
no env file in this patch?

> Signed-off-by: Manorit Chawdhry 
> Signed-off-by: Dasnavis Sabiya 
> Signed-off-by: Apurva Nandan 
> Reviewed-by: Tom Rini 

[...]

> diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
> new file mode 100644
> index 00..9e0df11503
> --- /dev/null
> +++ b/board/ti/j784s4/MAINTAINERS
> @@ -0,0 +1,14 @@
> +J784S4 EVM BOARD
> +M:   Apurva Nandan 
> +S:   Maintained
> +F:   board/ti/j784s4
> +F:   arch/arm/mach-k3/j784s4
> +F:   include/configs/j784s4_evm.h
> +F:   arch/arm/dts/k3-j784s4.dtsi
> +F:   arch/arm/dts/k3-j784s4-main.dtsi
> +F:   arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
> +F:   arch/arm/dts/k3-j784s4-thermal.dtsi
> +F:   arch/arm/dts/k3-j784s4-evm.dts
> +
> +AM69 SK BOARD
Don't all entries need a maintainer? I am not actually sure if the above
M will fall through for SK board.

> +F:   arch/arm/dts/k3-am69-sk.dts
> diff --git a/board/ti/j784s4/Makefile b/board/ti/j784s4/Makefile
> new file mode 100644
> index 00..60161a8b5c
> --- /dev/null
> +++ b/board/ti/j784s4/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +# Copyright (C) 2023-2024 Texas Instruments Incorporated - 
> https://www.ti.com/
> +#Hari Nagalla 
> +#
> +
> +obj-y += evm.o
> diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
> new file mode 100644
> index 00..5af3e21ff0
> --- /dev/null
> +++ b/board/ti/j784s4/evm.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Board specific initialization for J784S4 EVM
> + *
> + * Copyright (C) 2023-2024 Texas Instruments Incorporated - 
> https://www.ti.com/
> + *   Hari Nagalla 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Are you sure we need all the above headers?

> +#include "../common/fdt_ops.h"
[...]

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


Re: [PATCH v8 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition

2024-01-19 Thread Nishanth Menon
On 23:20-20240119, Apurva Nandan wrote:

[...]

> +void k3_spl_init(void)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + /*
> +  * Cannot delay this further as there is a chance that
> +  * K3_BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
> +  */
> + store_boot_info_from_rom();
> +
> + /* Make all control module registers accessible */
> + ctrl_mmr_unlock();
> +
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + disable_linefill_optimization();
> + setup_k3_mpu_regions();
> + }
> +
> + /* Init DM early */
> + ret = spl_early_init();
> +
> + /* Prepare console output */
> + preloader_console_init();
> +
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + /*
> +  * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and 
> continue
> +  * regardless of the result of pinctrl. Do this without probing 
> the
> +  * device, but instead by searching the device that would 
> request the
> +  * given sequence number if probed. The UART will be used by 
> the system
> +  * firmware (SYSFW) image for various purposes and SYSFW 
> depends on us

Nit pick - there is no SYSFW image anymore - it is either TIFS or DM.

> +  * to initialize its pin settings.
> +  */
> + ret = uclass_find_device_by_seq(UCLASS_SERIAL, 0, );
> + if (!ret)
> + pinctrl_select_state(dev, "default");
> +
> + /*
> +  * Load, start up, and configure system controller firmware. 
> Provide
> +  * the U-Boot console init function to the SYSFW post-PM 
> configuration
> +  * callback hook, effectively switching on (or over) the console
> +  * output.
> +  */
> + k3_sysfw_loader(is_rom_loaded_sysfw(), NULL, NULL);
> +
> + if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
> + /*
> +  * Force probe of clk_k3 driver here to ensure basic 
> default clock
> +  * configuration is always done for enabling PM 
> services.
> +  */
> + ret = uclass_get_device_by_driver(UCLASS_CLK,
> +   DM_DRIVER_GET(ti_clk),
> +   );
> + if (ret)
> + panic("Failed to initialize clk-k3!\n");
> + }
> +
> + remove_fwl_configs(cbass_hc_cfg0_fwls, 
> ARRAY_SIZE(cbass_hc_cfg0_fwls));
> + remove_fwl_configs(cbass_hc2_fwls, ARRAY_SIZE(cbass_hc2_fwls));
> + remove_fwl_configs(cbass_rc_cfg0_fwls, 
> ARRAY_SIZE(cbass_rc_cfg0_fwls));
> + remove_fwl_configs(infra_cbass0_fwls, 
> ARRAY_SIZE(infra_cbass0_fwls));
> + remove_fwl_configs(mcu_cbass0_fwls, 
> ARRAY_SIZE(mcu_cbass0_fwls));
> + remove_fwl_configs(wkup_cbass0_fwls, 
> ARRAY_SIZE(wkup_cbass0_fwls));
> + remove_fwl_configs(navss_cbass0_fwls, 
> ARRAY_SIZE(navss_cbass0_fwls));
> + }
> +
> + /* Output System Firmware version info */
> + k3_sysfw_print_ver();
> +}
> +
> +void k3_mem_init(void)
> +{
> + struct udevice *dev;
> + int ret, ctr = 1;
> +
> + if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
> + ret = uclass_get_device(UCLASS_RAM, 0, );
> + if (ret)
> + panic("DRAM 0 init failed: %d\n", ret);
> +
> + while (dev) {
why loop on dev? is it possible to have ret != 0 and dev = 0?

> + ret = uclass_next_device_err();
> + if (ret) {
> + printf("Initialized %d DRAM controllers\n", 
> ctr);
> + break;
> + }
> + ctr++;

What is the use of ctr++ ?? please do a limit check for instances.

[...]

Next time, please respond to the review comment questions so that I
know that you have considered and decided something is not necessary
or something was missed in the new version - for example what happened
to mmc_stop/restart?

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


Re: [PATCH v8 04/16] arm: dts: Add bootph-all for memory node

2024-01-19 Thread Nishanth Menon
On 23:20-20240119, Apurva Nandan wrote:
[...]

> diff --git a/arch/arm/dts/k3-am69-sk.dts b/arch/arm/dts/k3-am69-sk.dts
> index 9868c7049b..29884097b9 100644
> --- a/arch/arm/dts/k3-am69-sk.dts
> +++ b/arch/arm/dts/k3-am69-sk.dts

I think you mis-interpreted
https://lore.kernel.org/u-boot/20240103175221.ovjzcwwljnjhka2n@expire/
comment to modify kernel board.dts. I meant for you to squash that
correct change  to the patch that introduces board-u-boot.dtsi and r5.dts

Now that i read my comment, I can see why it might have been
mis-interpreted. Sorry about that - please squash your v7 patch
instead to appropriate patch.

> @@ -33,6 +33,7 @@
>  
>   memory@8000 {
>   device_type = "memory";
> + bootph-all;
>   /* 32G RAM */
>   reg = <0x00 0x8000 0x00 0x8000>,
> <0x08 0x8000 0x07 0x8000>;
> diff --git a/arch/arm/dts/k3-j784s4-evm.dts b/arch/arm/dts/k3-j784s4-evm.dts
> index f1f4c8634a..662552c872 100644
> --- a/arch/arm/dts/k3-j784s4-evm.dts
> +++ b/arch/arm/dts/k3-j784s4-evm.dts
> @@ -31,6 +31,7 @@
>  
>   memory@8000 {
>   device_type = "memory";
> + bootph-all;
>   /* 32G RAM */
>   reg = <0x00 0x8000 0x00 0x8000>,
> <0x08 0x8000 0x07 0x8000>;
> -- 
> 2.34.1
> 

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


Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files

2024-01-19 Thread Nishanth Menon
On 23:20-20240119, Apurva Nandan wrote:
[...]

> diff --git a/arch/arm/dts/k3-j784s4-binman.dtsi 
> b/arch/arm/dts/k3-j784s4-binman.dtsi
> new file mode 100644
> index 00..d0d49b5bbe
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-binman.dtsi
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include "k3-binman.dtsi"
> +
> +#ifdef CONFIG_TARGET_J784S4_R5_EVM
> +
> +_yaml_tifs {
> + config = "tifs-rm-cfg.yaml";
> +};
> +
> + {
> + tiboot3-j784s4-hs-evm.bin {
> + filename = "tiboot3-j784s4-hs-evm.bin";
> +

https://lore.kernel.org/u-boot/20240103174756.xa4rzbn4klk5gv2x@aware/

You haven't responded on thread why
"Prefer #1 - j784s4 binman template" is not feasible or not desirable.

Something like:

in j784s4-binman.dtsi:


  {
j784s4_tiboot3_hs_fs_template: template-9 {

and then in sk.dtsi:

 {
  ti-j784s4-hs-evm.bin {
 insert-template =<_tiboot3_hs_fs_template>;
 };
};

This allows boards to readily include the template for the binaries of
choice and generate just relevant output. Wont it save much confusion?

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


Re: [PATCH v8 15/16] configs: Add am69_sk_* defconfig fragments

2024-01-19 Thread Andrew Davis

On 1/19/24 11:50 AM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add config fragments for am69_sk A72 and R5 configuration.

This applies on to:
j784s4_evm_a72_defconfig -> am69_sk_a72.config
j784s4_evm_r5_defconfig -> am69_sk_r5.config

The usage model (with the fragment) would be:
make j784s4_evm_a72_defconfig am69_sk_a72.config
make

OR

make j784s4_evm_r5_defconfig am69_sk_r5.config
make

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
  board/ti/j784s4/MAINTAINERS | 2 ++
  configs/am69_sk_a72.config  | 5 +
  configs/am69_sk_r5.config   | 5 +
  3 files changed, 12 insertions(+)
  create mode 100644 configs/am69_sk_a72.config
  create mode 100644 configs/am69_sk_r5.config

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 4433ead66b..69be13f533 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -20,3 +20,5 @@ AM69 SK BOARD
  F:arch/arm/dts/k3-am69-sk.dts
  F:arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5.config
+F: configs/am69_sk_a72.config
diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
new file mode 100644
index 00..03e74a8a56
--- /dev/null
+++ b/configs/am69_sk_a72.config


Just going to ignore the comments on v7 about putting this
in board/ti/..?

Anyway, we can now do includes in defconfigs, so no config
fragments needed, you can just add `configs/am69_evm_a72_defconfig`
with the content:

```
#include 

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J784S4=y
CONFIG_TARGET_J784S4_A72_EVM=y

CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
CONFIG_SPL_OF_LIST="k3-am69-sk"
CONFIG_OF_LIST="k3-am69-sk"
```

(note we need to duplicate the _ARM/_TARGET currently to
not confuse buildman which seems to directly parse the configs
for arch detection).

Andrew


@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-sk"
+CONFIG_OF_LIST="k3-am69-sk"
diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
new file mode 100644
index 00..c42b6f3380
--- /dev/null
+++ b/configs/am69_sk_r5.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"


Re: [PATCH v1] net: sun8i-emac: Add support for fixed-link phy

2024-01-19 Thread Maxim Kiselev
Hi Andre,

пт, 19 янв. 2024 г. в 20:35, Andre Przywara :
>
> On Tue, 16 Jan 2024 19:58:56 +0300
> Maxim Kiselev  wrote:
>
> Hi Maxim,
>
> > вт, 16 янв. 2024 г. в 03:18, Andre Przywara :
> > >
> > > On Thu, 15 Jun 2023 00:44:06 +0300
> > > Maxim Kiselev  wrote:
> > >
> > > Hi Maxim,
> > >
> > > > From: Maksim Kiselev 
> > > >
> > > > Based on dt-specs fixed-link doesn't require phy-handle to be used.
> > >
> > > Do you have such a board?
> >
> > Yes, I had a custom board with T113 SoC which has fixed phy eth.
>
> So just to clarify: this board connected something like a switch directly
> to the MAC, just using RMII/RGMII? And then you have a fixed-phy node in
> the DT, detailing the speed and duplex parameters? Matching the fixed-phy
> node description in ethernet-controller.yaml? And drivers/net/phy/fixed.c
> takes care of parsing that?

Yes, you are absolutely right. The T113s connected directly to the switch port
via RMII interface. Here is the part of DT, that describes that configuration

 {
   pinctrl-names = "default";
   pinctrl-0 = <_pg_pins>;
   phy-mode = "rmii";
   snps,reset-gpio = < 4 12 GPIO_ACTIVE_LOW>; /* PE12 */
   allwinner,tx-delay-ps = <700>;
   allwinner,rx-delay-ps = <3100>;

   fixed-link {
   speed = <100>;
   full-duplex;
   };
};

>
> > > And where is that written down? I don't see
> > > it explicitly mentioned as optional in ethernet-controller.yaml or in
> > > the DT spec PDF.
> >
> > Sorry for that commit description. I just found the similar commit, that
> > fixes the same problem for zynq_gem
> > 3888c8d1979289efe685fe29276aed4d4b685975 ("net: zynq_gem: Add support for
> > fixed-link phy") and copied the description from there.
> >
> > > The sun8i EMAC binding lists phy-handle as required,
> > > so that would need to be relaxed there then.
> >
> > Oh, indeed. So it will require to send dt-binding changes to Linux first...
> >
> > Therefore, I think we can live without fixed-phy support for sun8i EMAC.
> > At least until some device with such a configuration appears on the
> > market :)
>
> Well, I am fine with that patch if it fixes a problem for you. It looks
> like requiring the phy-handle property is too strict, and just needs to be
> relaxed in the binding. If I see this correctly, the driver would still
> accept every valid DT, by today's and future bindings?
>
> If you could just confirm my above assumptions, and maybe send a v2 with an
> amended commit message, I would be happy to merge that patch.

Sure, I'll fix the commit description and send v2 asap.

> Cheers,
> Andre
>
> > > > Fix driver to only read phy related setting when phy-handle is found.
> > >
> > > The patch itself looks fine, we already specify -1 as the default when
> > > the PHY DT node does not contain a reg property, so that looks like it
> > > would work.
> > >
> > > Cheers,
> > > Andre
> > >
> > > > Signed-off-by: Maksim Kiselev 
> > > > ---
> > > >  drivers/net/sun8i_emac.c | 7 ++-
> > > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > > index 04c3274fbe..0e339d69e0 100644
> > > > --- a/drivers/net/sun8i_emac.c
> > > > +++ b/drivers/net/sun8i_emac.c
> > > > @@ -834,11 +834,8 @@ static int sun8i_emac_eth_of_to_plat(struct 
> > > > udevice *dev)
> > > >   priv->use_internal_phy = false;
> > > >
> > > >   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "phy-handle");
> > > > - if (offset < 0) {
> > > > - debug("%s: Cannot find PHY address\n", __func__);
> > > > - return -EINVAL;
> > > > - }
> > > > - priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
> > > > + if (offset >= 0)
> > > > + priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, 
> > > > "reg", -1);
> > > >
> > > >   pdata->phy_interface = dev_read_phy_mode(dev);
> > > >   debug("phy interface %d\n", pdata->phy_interface);
> > >
> >
> > Best wishes,
> > Maksim
>

Best wishes,
Maksim


Re: [PATCH] wdt: add HiSilicon watchdog driver support

2024-01-19 Thread Yang Xiwen
ic const struct wdt_ops hisi_wdt_ops = {
+   .start  = hisi_wdt_start,
+   .stop   = hisi_wdt_stop,
+   .reset  = hisi_wdt_reset,
+   .expire_now = hisi_wdt_expire_now,
+};
+
+static int hisi_wdt_probe(struct udevice *dev)
+{
+   struct hisi_wdt_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   ret = clk_prepare_enable(priv->clk);
+   if (ret) {
+   dev_err(dev, "failed to enable clk: %d\n", ret);
+   return log_msg_ret("clk", ret);
+   }
+
+   ret = reset_assert(priv->rst);
+   if (ret) {
+   dev_err(dev, "failed to assert reset: %d\n", ret);
+   return log_msg_ret("rst", ret);
+   }
+
+   udelay(10);
+
+   ret = reset_deassert(priv->rst);
+   if (ret) {
+   dev_err(dev, "failed to deassert reset: %d\n", ret);
+   return log_msg_ret("rst", ret);
+   }
+
+   return 0;
+}
+
+static int hisi_wdt_of_to_plat(struct udevice *dev)
+{
+   struct hisi_wdt_priv *priv = dev_get_priv(dev);
+
+   priv->reg = dev_remap_addr(dev);
+   if (!priv->reg) {
+   dev_err(dev, "failed to remap\n");
+   return log_msg_ret("wdt", -EINVAL);
+   }
+
+   priv->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(priv->clk)) {
+   dev_err(dev, "failed to get clk: %ld\n", PTR_ERR(priv->clk));
+   return log_msg_ret("wdt", PTR_ERR(priv->clk));
+   }
+
+   priv->rst = devm_reset_control_get(dev, NULL);
+   if (IS_ERR(priv->rst)) {
+   dev_err(dev, "failed to get rst: %ld\n", PTR_ERR(priv->rst));
+   return log_msg_ret("wdt", PTR_ERR(priv->rst));
+   }
+
+   return 0;
+}
+
+static const struct udevice_id hisi_wdt_ids[] = {
+   { .compatible = "hisilicon,wdt" },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(hisi_wdt) = {
+   .name   = "hisilicon_wdt",
+   .id = UCLASS_WDT,
+   .of_match   = hisi_wdt_ids,
+   .of_to_plat = hisi_wdt_of_to_plat,
+   .probe  = hisi_wdt_probe,
+   .priv_auto  = sizeof(struct hisi_wdt_priv),
+   .ops= _wdt_ops,
+};

---
base-commit: 842c5b501be7fe23f618788002c5e81fd56ac382
change-id: 20240119-b4-wdt-d51eb3ae62c9

Best regards,


I recently found that this is just a plain sp805 watchdog. Please just 
ignore this patch.


--
Regards,
Yang Xiwen



[PATCH v8 16/16] doc: board: ti: k3: Add J784S4 EVM and AM69 SK documentation

2024-01-19 Thread Apurva Nandan
TI K3 J784S4 and AM69 are new additions to the K3 SoC family.
Add documentation about the J784S4 EVM and AM69 SK.

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
 board/ti/j784s4/MAINTAINERS |   1 +
 doc/board/ti/j784s4_evm.rst | 299 
 doc/board/ti/k3.rst |   1 +
 3 files changed, 301 insertions(+)
 create mode 100644 doc/board/ti/j784s4_evm.rst

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 69be13f533..f61ecce632 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -15,6 +15,7 @@ F:arch/arm/dts/k3-j784s4-evm-u-boot.dtsi
 F: arch/arm/dts/k3-j784s4-r5-evm.dts
 F: arch/arm/dts/k3-j784s4-ddr.dtsi
 F: arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi
+F: doc/board/ti/j784s4_evm.rst
 
 AM69 SK BOARD
 F: arch/arm/dts/k3-am69-sk.dts
diff --git a/doc/board/ti/j784s4_evm.rst b/doc/board/ti/j784s4_evm.rst
new file mode 100644
index 00..a85d52ff19
--- /dev/null
+++ b/doc/board/ti/j784s4_evm.rst
@@ -0,0 +1,299 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+.. sectionauthor:: Apurva Nandan 
+
+J784S4 and AM69 Platforms
+=
+
+Introduction
+
+The J784S4 SoC belongs to the K3 Multicore SoC architecture
+platform, providing advanced system integration in automotive,
+ADAS and industrial applications requiring AI at the network edge.
+This SoC extends the K3 Jacinto 7 family of SoCs with focus on
+raising performance and integration while providing interfaces,
+memory architecture and compute performance for multi-sensor, high
+concurrency applications.
+
+The device is partitioned into three functional domains, each containing
+specific processing cores and peripherals:
+
+1. Wake-up (WKUP) domain
+* ARM Cortex-M4F processor, runs TI Foundational Security (TIFS)
+
+2. Microcontroller (MCU) domain
+* Dual core ARM Cortex-R5F processor, runs device management
+  and SoC early boot
+
+3. MAIN domain
+* Two clusters of quad core 64-bit ARM Cortex-A72, runs HLOS
+* Dual core ARM Cortex-R5F processor used for RTOS applications
+* Four C7x DSPs used for Machine Learning applications.
+
+
+More info can be found in TRM: http://www.ti.com/lit/zip/spruj52
+
+Platform information:
+
+* https://www.ti.com/tool/J784S4XEVM
+* https://www.ti.com/tool/SK-AM69
+
+Boot Flow
+-
+Below is the pictorial representation of boot flow:
+
+.. image:: img/boot_diagram_k3_current.svg
+:alt: K3 boot flow
+
+- On this platform, "TI Foundational Security" (TIFS) functions as the
+  security enclave master. While "Device Manager" (DM), also known as the
+  "TISCI server" in TI terminology, offers all the essential services.
+
+- As illustrated in the diagram above, R5 SPL manages power and clock
+  services independently before handing over control to DM. The A72 or
+  the C7x (Aux core) software components request TIFS/DM to handle
+  security or device management services.
+
+Sources
+---
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure
+---
+0. Setup the environment variables:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=j784s4_evm_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=j784s4_evm_a72_defconfig
+ $ export TFA_BOARD=j784s4
+ $ export TFA_EXTRA_ARGS="K3_USART=0x8"
+ $ export OPTEE_PLATFORM=k3-j784s4
+ $ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8"
+
+.. j784s4_evm_rst_include_start_build_steps
+
+1. Trusted Firmware-A
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_build_steps_tfa
+:end-before: .. k3_rst_include_end_build_steps_tfa
+
+
+2. OP-TEE
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_build_steps_optee
+:end-before: .. k3_rst_include_end_build_steps_optee
+
+3. U-Boot
+
+.. _j784s4_evm_rst_u_boot_r5:
+
+* 3.1 R5
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_build_steps_spl_r5
+:end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+.. _j784s4_evm_rst_u_boot_a72:
+
+* 3.2 A72
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_build_steps_uboot
+:end-before: .. k3_rst_include_end_build_steps_uboot
+.. j784s4_evm_rst_include_end_build_steps
+
+Target Images
+-
+In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC
+variant (GP, HS-FS, HS-SE) requires a different source for 

[PATCH v8 15/16] configs: Add am69_sk_* defconfig fragments

2024-01-19 Thread Apurva Nandan
From: Dasnavis Sabiya 

Add config fragments for am69_sk A72 and R5 configuration.

This applies on to:
j784s4_evm_a72_defconfig -> am69_sk_a72.config
j784s4_evm_r5_defconfig -> am69_sk_r5.config

The usage model (with the fragment) would be:
make j784s4_evm_a72_defconfig am69_sk_a72.config
make

OR

make j784s4_evm_r5_defconfig am69_sk_r5.config
make

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
 board/ti/j784s4/MAINTAINERS | 2 ++
 configs/am69_sk_a72.config  | 5 +
 configs/am69_sk_r5.config   | 5 +
 3 files changed, 12 insertions(+)
 create mode 100644 configs/am69_sk_a72.config
 create mode 100644 configs/am69_sk_r5.config

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 4433ead66b..69be13f533 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -20,3 +20,5 @@ AM69 SK BOARD
 F: arch/arm/dts/k3-am69-sk.dts
 F: arch/arm/dts/k3-am69-sk-u-boot.dtsi
 F: arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5.config
+F: configs/am69_sk_a72.config
diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
new file mode 100644
index 00..03e74a8a56
--- /dev/null
+++ b/configs/am69_sk_a72.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-sk"
+CONFIG_OF_LIST="k3-am69-sk"
diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
new file mode 100644
index 00..c42b6f3380
--- /dev/null
+++ b/configs/am69_sk_r5.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"
-- 
2.34.1



[PATCH v8 14/16] configs: j784s4_evm: Add defconfig for j784s4 evm board

2024-01-19 Thread Apurva Nandan
Add defconfigs for building R5 U-Boot SPL and A72 U-Boot.

Signed-off-by: Hari Nagalla 
Signed-off-by: Apurva Nandan 
---
 board/ti/j784s4/MAINTAINERS  |   2 +
 configs/j784s4_evm_a72_defconfig | 158 +++
 configs/j784s4_evm_r5_defconfig  | 153 ++
 3 files changed, 313 insertions(+)
 create mode 100644 configs/j784s4_evm_a72_defconfig
 create mode 100644 configs/j784s4_evm_r5_defconfig

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 53bc4bab03..4433ead66b 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -4,6 +4,8 @@ S:  Maintained
 F: board/ti/j784s4
 F: arch/arm/mach-k3/j784s4
 F: include/configs/j784s4_evm.h
+F: configs/j784s4_evm_r5_defconfig
+F: configs/j784s4_evm_a72_defconfig
 F: arch/arm/dts/k3-j784s4.dtsi
 F: arch/arm/dts/k3-j784s4-main.dtsi
 F: arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
diff --git a/configs/j784s4_evm_a72_defconfig b/configs/j784s4_evm_a72_defconfig
new file mode 100644
index 00..2ab1297cfc
--- /dev/null
+++ b/configs/j784s4_evm_a72_defconfig
@@ -0,0 +1,158 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_J784S4=y
+CONFIG_TARGET_J784S4_A72_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
+CONFIG_SF_DEFAULT_SPEED=2500
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-j784s4-evm"
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+CONFIG_BOOTSTD_FULL=y
+CONFIG_BOOTSTD_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_LOGLEVEL=7
+CONFIG_SPL_MAX_SIZE=0xc
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x80a0
+CONFIG_SPL_BSS_MAX_SIZE=0x8
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_SYS_SPL_MALLOC_SIZE=0x80
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
+CONFIG_SPL_I2C=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
+CONFIG_SPL_THERMAL=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_SYS_MAXARGS=64
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_OF_LIST="k3-j784s4-evm"
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_CCF=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_CFI_FLASH=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HX_T=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
+CONFIG_SPI_FLASH_MTD=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
+CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_FIXED=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_TORRENT=y
+CONFIG_PHY_J721E_WIZ=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
+CONFIG_DM_SERIAL=y

[PATCH v8 13/16] arm: dts: Introduce am69-sk u-boot dts files

2024-01-19 Thread Apurva Nandan
From: Dasnavis Sabiya 

Introduce the base dts files needed for u-boot or to augment the linux
dtbs for use in the u-boot-spl and u-boot binaries.

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/k3-am69-r5-sk.dts  | 105 
 arch/arm/dts/k3-am69-sk-u-boot.dtsi |  48 +
 board/ti/j784s4/MAINTAINERS |   2 +
 4 files changed, 156 insertions(+)
 create mode 100644 arch/arm/dts/k3-am69-r5-sk.dts
 create mode 100644 arch/arm/dts/k3-am69-sk-u-boot.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 876802b88e..1c5a6662f6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1412,6 +1412,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
   k3-j721s2-r5-common-proc-board.dtb
 
 dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-sk.dtb \
+  k3-am69-r5-sk.dtb \
   k3-j784s4-evm.dtb \
   k3-j784s4-r5-evm.dtb
 
diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts
new file mode 100644
index 00..d2e73bd1bf
--- /dev/null
+++ b/arch/arm/dts/k3-am69-r5-sk.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am69-sk.dts"
+#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
+#include "k3-j784s4-ddr.dtsi"
+#include "k3-am69-sk-u-boot.dtsi"
+
+/ {
+   chosen {
+   tick-timer = _timer0;
+   };
+
+   aliases {
+   remoteproc0 = 
+   remoteproc1 = _0;
+   };
+
+   a72_0: a72@0 {
+   compatible = "ti,am654-rproc";
+   reg = <0x0 0x00a9 0x0 0x10>;
+   power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+   <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+   resets = <_reset 202 0>;
+   clocks = <_clks 61 0>;
+   assigned-clocks = <_clks 61 0>, <_clks 202 0>;
+   assigned-clock-parents = <_clks 61 2>;
+   assigned-clock-rates = <2>, <20>;
+   ti,sci = <>;
+   ti,sci-proc-id = <32>;
+   ti,sci-host-id = <10>;
+   bootph-pre-ram;
+   };
+
+   dm_tifs: dm-tifs {
+   compatible = "ti,j721e-dm-sci";
+   ti,host-id = <3>;
+   ti,secure-host;
+   mbox-names = "rx", "tx";
+   mboxes= <_proxy_mcu 21>, <_proxy_mcu 23>;
+   bootph-pre-ram;
+   };
+};
+
+_timer0 {
+   status = "okay";
+   clock-frequency = <25000>;
+   bootph-pre-ram;
+};
+
+_proxy_sa3 {
+   status = "okay";
+   bootph-pre-ram;
+};
+
+_proxy_mcu {
+   status = "okay";
+   bootph-pre-ram;
+};
+
+_mcu_wakeup {
+   sysctrler: sysctrler {
+   compatible = "ti,am654-system-controller";
+   mboxes= <_proxy_mcu 4>,
+   <_proxy_mcu 5>,
+   <_proxy_sa3 5>;
+   mbox-names = "tx", "rx", "boot_notify";
+   bootph-pre-ram;
+   };
+};
+
+ {
+   mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>, 
<_proxy_mcu 5>;
+   mbox-names = "tx", "rx", "notify";
+   ti,host-id = <4>;
+   ti,secure-host;
+   bootph-pre-ram;
+};
+
+_uart0 {
+   bootph-pre-ram;
+   status = "okay";
+};
+
+ {
+   reg = <0x0 0x4704 0x0 0x100>,
+ <0x0 0x5000 0x0 0x800>;
+};
+
+ {
+   reg = <0x0 0x4705 0x0 0x100>,
+ <0x0 0x5800 0x0 0x800>;
+};
+
+_ringacc {
+   ti,sci = <_tifs>;
+};
+
+_udmap {
+   ti,sci = <_tifs>;
+};
diff --git a/arch/arm/dts/k3-am69-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
new file mode 100644
index 00..4f8c99a1e6
--- /dev/null
+++ b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-j784s4-binman.dtsi"
+
+_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-pre-ram;
+};
+
+ {
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   bootph-pre-ram;
+   };
+};
+
+#ifdef CONFIG_TARGET_J784S4_A72_EVM
+
+#define SPL_AM69_SK_DTB "spl/dts/k3-am69-sk.dtb"
+#define AM69_SK_DTB "arch/arm/dts/k3-am69-sk.dtb"
+
+_j784s4_evm_dtb {
+   filename = SPL_AM69_SK_DTB;
+};
+
+_evm_dtb {
+   filename = AM69_SK_DTB;
+};
+

[PATCH v8 11/16] board: ti: j784s4: Add boot environment variables

2024-01-19 Thread Apurva Nandan
Add env file with necessary boot variables.

Signed-off-by: Apurva Nandan 
---
 board/ti/j784s4/j784s4.env | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 board/ti/j784s4/j784s4.env

diff --git a/board/ti/j784s4/j784s4.env b/board/ti/j784s4/j784s4.env
new file mode 100644
index 00..7e54ca042e
--- /dev/null
+++ b/board/ti/j784s4/j784s4.env
@@ -0,0 +1,17 @@
+#include 
+#include 
+#include 
+#include 
+
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0288
+   ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+
+boot_targets=mmc1 mmc0 usb pxe dhcp
+boot=mmc
+mmcdev=1
+bootpart=1:2
+bootdir=/boot
+rd_spec=-
-- 
2.34.1



[PATCH v8 09/16] board: ti: j784s4: Add board support for J784S4 EVM

2024-01-19 Thread Apurva Nandan
Add board files for J784S4 EVM.

SYS_DISABLE_DCACHE_OPS is selected in the Kconfig because
J784S4/AM69 are a coherent architecture at A72 level by
MSMC support.

Signed-off-by: Hari Nagalla 
[ add env and board specific yaml files for binman ]
Signed-off-by: Neha Malcom Francis 
[ cleaned up the env files ]
Signed-off-by: Manorit Chawdhry 
Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
Reviewed-by: Tom Rini 
---
 arch/arm/mach-k3/Kconfig|  1 +
 arch/arm/mach-k3/j784s4/Kconfig | 34 ++
 board/ti/j784s4/Kconfig | 37 
 board/ti/j784s4/MAINTAINERS | 14 +++
 board/ti/j784s4/Makefile|  7 ++
 board/ti/j784s4/evm.c   | 43 +
 include/configs/j784s4_evm.h| 15 
 7 files changed, 151 insertions(+)
 create mode 100644 arch/arm/mach-k3/j784s4/Kconfig
 create mode 100644 board/ti/j784s4/Kconfig
 create mode 100644 board/ti/j784s4/MAINTAINERS
 create mode 100644 board/ti/j784s4/Makefile
 create mode 100644 board/ti/j784s4/evm.c
 create mode 100644 include/configs/j784s4_evm.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 217def3bb4..fdde67c2d3 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -157,5 +157,6 @@ source "arch/arm/mach-k3/am62x/Kconfig"
 source "arch/arm/mach-k3/am62ax/Kconfig"
 source "arch/arm/mach-k3/j721e/Kconfig"
 source "arch/arm/mach-k3/j721s2/Kconfig"
+source "arch/arm/mach-k3/j784s4/Kconfig"
 
 endif
diff --git a/arch/arm/mach-k3/j784s4/Kconfig b/arch/arm/mach-k3/j784s4/Kconfig
new file mode 100644
index 00..1eadfb346a
--- /dev/null
+++ b/arch/arm/mach-k3/j784s4/Kconfig
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023-2024 Texas Instruments Incorporated - https://www.ti.com/
+#  Hari Nagalla 
+
+if SOC_K3_J784S4
+
+choice
+   prompt "K3 J784S4 board"
+   optional
+
+config TARGET_J784S4_A72_EVM
+   bool "TI K3 based J784S4 EVM running on A72"
+   select ARM64
+   select BOARD_LATE_INIT
+   select SYS_DISABLE_DCACHE_OPS
+   select BINMAN
+
+config TARGET_J784S4_R5_EVM
+   bool "TI K3 based J784S4 EVM running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select K3_LOAD_SYSFW
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
+   select BINMAN
+   imply SYS_K3_SPL_ATF
+
+endchoice
+
+source "board/ti/j784s4/Kconfig"
+
+endif
diff --git a/board/ti/j784s4/Kconfig b/board/ti/j784s4/Kconfig
new file mode 100644
index 00..490c7be66b
--- /dev/null
+++ b/board/ti/j784s4/Kconfig
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023-2024 Texas Instruments Incorporated - https://www.ti.com/
+#  Hari Nagalla 
+
+if TARGET_J784S4_A72_EVM
+
+config SYS_BOARD
+   default "j784s4"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "j784s4_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_J784S4_R5_EVM
+
+config SYS_BOARD
+   default "j784s4"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "j784s4_evm"
+
+config SPL_LDSCRIPT
+   default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+source "board/ti/common/Kconfig"
+
+endif
diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
new file mode 100644
index 00..9e0df11503
--- /dev/null
+++ b/board/ti/j784s4/MAINTAINERS
@@ -0,0 +1,14 @@
+J784S4 EVM BOARD
+M: Apurva Nandan 
+S: Maintained
+F: board/ti/j784s4
+F: arch/arm/mach-k3/j784s4
+F: include/configs/j784s4_evm.h
+F: arch/arm/dts/k3-j784s4.dtsi
+F: arch/arm/dts/k3-j784s4-main.dtsi
+F: arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
+F: arch/arm/dts/k3-j784s4-thermal.dtsi
+F: arch/arm/dts/k3-j784s4-evm.dts
+
+AM69 SK BOARD
+F: arch/arm/dts/k3-am69-sk.dts
diff --git a/board/ti/j784s4/Makefile b/board/ti/j784s4/Makefile
new file mode 100644
index 00..60161a8b5c
--- /dev/null
+++ b/board/ti/j784s4/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023-2024 Texas Instruments Incorporated - https://www.ti.com/
+#  Hari Nagalla 
+#
+
+obj-y += evm.o
diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
new file mode 100644
index 00..5af3e21ff0
--- /dev/null
+++ b/board/ti/j784s4/evm.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Board specific initialization for J784S4 EVM
+ *
+ * Copyright (C) 2023-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "../common/fdt_ops.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+   return fdtdec_setup_memory_banksize();
+}
+
+#ifdef 

[PATCH v8 08/16] drivers: dma: Add support for J784S4 SoC

2024-01-19 Thread Apurva Nandan
Add support for DMA in J784S4 SoC.

Signed-off-by: Jayesh Choudhary 
Signed-off-by: Hari Nagalla 
Signed-off-by: Apurva Nandan 
Reviewed-by: Nishanth Menon 
---
 drivers/dma/ti/Makefile   |   1 +
 drivers/dma/ti/k3-psil-j784s4.c   | 166 ++
 drivers/dma/ti/k3-psil-priv.h |   1 +
 drivers/dma/ti/k3-psil.c  |   2 +
 drivers/firmware/ti_sci_static_data.h |  34 ++
 drivers/ram/Kconfig   |   2 +-
 6 files changed, 205 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/ti/k3-psil-j784s4.c

diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index f4e0271efb..9e0b13e8c0 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -9,3 +9,4 @@ k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
 k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
 k3-psil-data-$(CONFIG_SOC_K3_AM625) += k3-psil-am62.o
 k3-psil-data-$(CONFIG_SOC_K3_AM62A7) += k3-psil-am62a.o
+k3-psil-data-$(CONFIG_SOC_K3_J784S4) += k3-psil-j784s4.o
diff --git a/drivers/dma/ti/k3-psil-j784s4.c b/drivers/dma/ti/k3-psil-j784s4.c
new file mode 100644
index 00..7f06a1f307
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-j784s4.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ *  Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com
+ */
+#include 
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   },  \
+   }
+
+#define PSIL_PDMA_XY_PKT(x)\
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   .pkt_mode = 1,  \
+   },  \
+   }
+
+#define PSIL_PDMA_MCASP(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   .pdma_acc32 = 1,\
+   .pdma_burst = 1,\
+   },  \
+   }
+
+#define PSIL_ETHERNET(x)   \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 16, \
+   },  \
+   }
+
+#define PSIL_SA2UL(x, tx)  \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 64, \
+   .notdpkt = tx,  \
+   },  \
+   }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep j784s4_src_ep_map[] = {
+   /* PDMA_MCASP - McASP0-4 */
+   PSIL_PDMA_MCASP(0x4400),
+   PSIL_PDMA_MCASP(0x4401),
+   PSIL_PDMA_MCASP(0x4402),
+   PSIL_PDMA_MCASP(0x4403),
+   PSIL_PDMA_MCASP(0x4404),
+   /* PDMA_SPI_G0 - SPI0-3 */
+   PSIL_PDMA_XY_PKT(0x4600),
+   PSIL_PDMA_XY_PKT(0x4601),
+   PSIL_PDMA_XY_PKT(0x4602),
+   PSIL_PDMA_XY_PKT(0x4603),
+   PSIL_PDMA_XY_PKT(0x4604),
+   PSIL_PDMA_XY_PKT(0x4605),
+   PSIL_PDMA_XY_PKT(0x4606),
+   PSIL_PDMA_XY_PKT(0x4607),
+   PSIL_PDMA_XY_PKT(0x4608),
+   PSIL_PDMA_XY_PKT(0x4609),
+   PSIL_PDMA_XY_PKT(0x460a),
+   PSIL_PDMA_XY_PKT(0x460b),
+   PSIL_PDMA_XY_PKT(0x460c),
+   PSIL_PDMA_XY_PKT(0x460d),
+   PSIL_PDMA_XY_PKT(0x460e),
+   PSIL_PDMA_XY_PKT(0x460f),
+   /* PDMA_SPI_G1 - SPI4-7 */
+   PSIL_PDMA_XY_PKT(0x4610),
+   PSIL_PDMA_XY_PKT(0x4611),
+   PSIL_PDMA_XY_PKT(0x4612),
+   PSIL_PDMA_XY_PKT(0x4613),
+   PSIL_PDMA_XY_PKT(0x4614),
+   PSIL_PDMA_XY_PKT(0x4615),
+   PSIL_PDMA_XY_PKT(0x4616),
+   PSIL_PDMA_XY_PKT(0x4617),
+   

[PATCH v8 07/16] arm: mach-k3: j784s4: Add clk and power support

2024-01-19 Thread Apurva Nandan
Add clk and device data which can be used by respective drivers
to configure clocks and PSC.

Signed-off-by: Hari Nagalla 
Signed-off-by: Apurva Nandan 
Reviewed-by: Sean Anderson 
Reviewed-by: Nishanth Menon 
Reviewed-by: Bryan Brattlof 
---
 arch/arm/mach-k3/r5/j784s4/Makefile|   7 +
 arch/arm/mach-k3/r5/j784s4/clk-data.c  | 428 +
 arch/arm/mach-k3/r5/j784s4/dev-data.c  |  98 ++
 drivers/clk/ti/clk-k3.c|   6 +
 drivers/power/domain/ti-power-domain.c |   6 +
 include/k3-clk.h   |   1 +
 include/k3-dev.h   |   1 +
 7 files changed, 547 insertions(+)
 create mode 100644 arch/arm/mach-k3/r5/j784s4/Makefile
 create mode 100644 arch/arm/mach-k3/r5/j784s4/clk-data.c
 create mode 100644 arch/arm/mach-k3/r5/j784s4/dev-data.c

diff --git a/arch/arm/mach-k3/r5/j784s4/Makefile 
b/arch/arm/mach-k3/r5/j784s4/Makefile
new file mode 100644
index 00..9ce88305f5
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j784s4/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023-2024 Texas Instruments Incorporated - https://www.ti.com/
+#
+
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/r5/j784s4/clk-data.c 
b/arch/arm/mach-k3/r5/j784s4/clk-data.c
new file mode 100644
index 00..feaa13ee26
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j784s4/clk-data.c
@@ -0,0 +1,428 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * J784S4 specific clock platform data
+ *
+ * This file is auto generated. Please do not hand edit and report any issues
+ * to Bryan Brattlof .
+ *
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+   "osc_19_2_mhz",
+   "osc_20_mhz",
+   "osc_24_mhz",
+   "osc_25_mhz",
+   "osc_26_mhz",
+   "osc_27_mhz",
+};
+
+static const char * const mcu_ospi0_iclk_sel_out0_parents[] = {
+   "board_0_mcu_ospi0_dqs_out",
+   "fss_mcu_0_ospi_0_ospi_oclk_clk",
+};
+
+static const char * const mcu_ospi1_iclk_sel_out0_parents[] = {
+   "board_0_mcu_ospi1_dqs_out",
+   "fss_mcu_0_ospi_1_ospi_oclk_clk",
+};
+
+static const char * const wkup_fref_clksel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "j7am_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const k3_pll_ctrl_wrap_wkup_0_sysclkout_clk_parents[] = {
+   "wkup_fref_clksel_out0",
+   "hsdiv1_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+   "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out1_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+   "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const wkup_gpio0_clksel_out0_parents[] = {
+   "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+   "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+   "j7am_wakeup_16ff_wkup_0_wkup_rcosc_32k_clk",
+   "j7am_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const mcu_usart_clksel_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+   "postdiv3_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_i2c_mcupll_bypass_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+   "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out1_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out12_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out19_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out2_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out26_0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out27_0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out28_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out3_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out7_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out8_parents[] = {
+   

[PATCH v8 06/16] soc: ti: k3-socinfo: Add entry for J784S4 SoC

2024-01-19 Thread Apurva Nandan
Add support for J784S4 SoC Identification.

Signed-off-by: Hari Nagalla 
Signed-off-by: Apurva Nandan 
Reviewed-by: Nishanth Menon 
---
 arch/arm/mach-k3/include/mach/hardware.h | 1 +
 drivers/soc/soc_ti_k3.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index 7e143c6bdc..74692b745a 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -50,6 +50,7 @@
 #define JTAG_ID_PARTNO_J7200   0xbb6d
 #define JTAG_ID_PARTNO_J721E   0xbb64
 #define JTAG_ID_PARTNO_J721S2  0xbb75
+#define JTAG_ID_PARTNO_J784S4  0xbb80
 
 #define K3_SOC_ID(id, ID) \
 static inline bool soc_is_##id(void) \
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 355a5368dd..d176980915 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -45,6 +45,9 @@ static const char *get_family_string(u32 idreg)
case JTAG_ID_PARTNO_AM62AX:
family = "AM62AX";
break;
+   case JTAG_ID_PARTNO_J784S4:
+   family = "J784S4";
+   break;
default:
family = "Unknown Silicon";
};
-- 
2.34.1



[PATCH v8 05/16] arm: mach-k3: Sort SoC JTAG_ID entries

2024-01-19 Thread Apurva Nandan
Sort JTAG_IDs for K3 SoCs in hardware.h in alphabetical order.

Signed-off-by: Apurva Nandan 
Reviewed-by: Nishanth Menon 
---
 arch/arm/mach-k3/include/mach/hardware.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index 0cf1e12aaa..7e143c6bdc 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -43,13 +43,13 @@
 #define JTAG_ID_VARIANT_MASK   (0xf << 28)
 #define JTAG_ID_PARTNO_SHIFT   12
 #define JTAG_ID_PARTNO_MASK(0x << 12)
+#define JTAG_ID_PARTNO_AM62AX   0xbb8d
+#define JTAG_ID_PARTNO_AM62X   0xbb7e
+#define JTAG_ID_PARTNO_AM64X   0xbb38
 #define JTAG_ID_PARTNO_AM65X   0xbb5a
-#define JTAG_ID_PARTNO_J721E   0xbb64
 #define JTAG_ID_PARTNO_J7200   0xbb6d
-#define JTAG_ID_PARTNO_AM64X   0xbb38
+#define JTAG_ID_PARTNO_J721E   0xbb64
 #define JTAG_ID_PARTNO_J721S2  0xbb75
-#define JTAG_ID_PARTNO_AM62X   0xbb7e
-#define JTAG_ID_PARTNO_AM62AX   0xbb8d
 
 #define K3_SOC_ID(id, ID) \
 static inline bool soc_is_##id(void) \
-- 
2.34.1



[PATCH v8 04/16] arm: dts: Add bootph-all for memory node

2024-01-19 Thread Apurva Nandan
memory node is used by fdtdec_setup_mem_size_base() and
fdtdec_setup_memory_banksize() during dram_init(), so use
bootph-all to enable for all stages.

Signed-off-by: Apurva Nandan 
---
 arch/arm/dts/k3-am69-sk.dts| 1 +
 arch/arm/dts/k3-j784s4-evm.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/dts/k3-am69-sk.dts b/arch/arm/dts/k3-am69-sk.dts
index 9868c7049b..29884097b9 100644
--- a/arch/arm/dts/k3-am69-sk.dts
+++ b/arch/arm/dts/k3-am69-sk.dts
@@ -33,6 +33,7 @@
 
memory@8000 {
device_type = "memory";
+   bootph-all;
/* 32G RAM */
reg = <0x00 0x8000 0x00 0x8000>,
  <0x08 0x8000 0x07 0x8000>;
diff --git a/arch/arm/dts/k3-j784s4-evm.dts b/arch/arm/dts/k3-j784s4-evm.dts
index f1f4c8634a..662552c872 100644
--- a/arch/arm/dts/k3-j784s4-evm.dts
+++ b/arch/arm/dts/k3-j784s4-evm.dts
@@ -31,6 +31,7 @@
 
memory@8000 {
device_type = "memory";
+   bootph-all;
/* 32G RAM */
reg = <0x00 0x8000 0x00 0x8000>,
  <0x08 0x8000 0x07 0x8000>;
-- 
2.34.1



[PATCH v8 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition

2024-01-19 Thread Apurva Nandan
Add J784S4 initialization files for initial SPL boot.

config SYS_K3_MCU_SCRATCHPAD_BASE default value is same
for J721E, J721S2, J784S4. So combined them into a single
default.

Signed-off-by: Hari Nagalla 
[ add firewall configurations and change the R5 MCU scratchpad ]
Signed-off-by: Manorit Chawdhry 
Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
Reviewed-by: Neha Malcom Francis 
---
 arch/arm/mach-k3/Kconfig  |  16 +-
 arch/arm/mach-k3/Makefile |   2 +
 arch/arm/mach-k3/include/mach/hardware.h  |   4 +
 .../mach-k3/include/mach/j784s4_hardware.h|  59 
 arch/arm/mach-k3/include/mach/j784s4_spl.h|  47 +++
 arch/arm/mach-k3/include/mach/spl.h   |   4 +
 arch/arm/mach-k3/j784s4_fdt.c |  15 +
 arch/arm/mach-k3/j784s4_init.c| 305 ++
 arch/arm/mach-k3/r5/Makefile  |   1 +
 9 files changed, 446 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h
 create mode 100644 arch/arm/mach-k3/j784s4_fdt.c
 create mode 100644 arch/arm/mach-k3/j784s4_init.c

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index f0ed5c6128..217def3bb4 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -22,6 +22,9 @@ config SOC_K3_J721E
 config SOC_K3_J721S2
bool "TI's K3 based J721S2 SoC Family Support"
 
+config SOC_K3_J784S4
+   bool "TI's K3 based J784S4 SoC Family Support"
+
 endchoice
 
 if SOC_K3_J721E
@@ -35,7 +38,7 @@ config SYS_SOC
 config SYS_K3_NON_SECURE_MSRAM_SIZE
hex
default 0x8 if SOC_K3_AM654
-   default 0x10 if SOC_K3_J721E || SOC_K3_J721S2
+   default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
default 0x1c if SOC_K3_AM642
default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7
help
@@ -47,7 +50,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE
 config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
hex
default 0x58000 if SOC_K3_AM654
-   default 0xc if SOC_K3_J721E || SOC_K3_J721S2
+   default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
default 0x18 if SOC_K3_AM642
default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7
help
@@ -57,15 +60,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
 config SYS_K3_MCU_SCRATCHPAD_BASE
hex
default 0x4028 if SOC_K3_AM654
-   default 0x41cff9fc if SOC_K3_J721S2
-   default 0x41cff9fc if SOC_K3_J721E
+   default 0x41cff9fc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
help
  Describes the base address of MCU Scratchpad RAM.
 
 config SYS_K3_MCU_SCRATCHPAD_SIZE
hex
default 0x200 if SOC_K3_AM654
-   default 0x200 if SOC_K3_J721E || SOC_K3_J721S2
+   default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
help
  Describes the size of MCU Scratchpad RAM.
 
@@ -73,7 +75,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
hex
default 0x41c7fbfc if SOC_K3_AM654
default 0x41cffbfc if SOC_K3_J721E
-   default 0x41cfdbfc if SOC_K3_J721S2
+   default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4
default 0x701bebfc if SOC_K3_AM642
default 0x43c3f290 if SOC_K3_AM625
default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
@@ -130,7 +132,7 @@ config K3_ATF_LOAD_ADDR
 
 config K3_DM_FW
bool "Separate DM firmware image"
-   depends on CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || 
SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN
+   depends on CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || 
SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN
default y
help
  Enabling this will indicate that the system has separate DM
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 4216137646..945698e6e8 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
 obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
 obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
+obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
 endif
 ifeq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
@@ -20,5 +21,6 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
 obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
 obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
 obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
+obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o
 endif
 obj-y += common.o security.o
diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index a1a9dfbde6..0cf1e12aaa 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -33,6 +33,10 @@
 #include "am62a_qos.h"
 #endif
 
+#ifdef CONFIG_SOC_K3_J784S4
+#include 

[PATCH v8 01/16] arm: mach-k3: Kconfig: Sort SOC_K3 config entries

2024-01-19 Thread Apurva Nandan
Sort SOC_K3 config entries in alphabetical order
for clean up.

Signed-off-by: Apurva Nandan 
---
 arch/arm/mach-k3/Kconfig | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 03898424c9..f0ed5c6128 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -4,6 +4,15 @@ choice
prompt "Texas Instruments' K3 based SoC select"
optional
 
+config SOC_K3_AM625
+   bool "TI's K3 based AM625 SoC Family Support"
+
+config SOC_K3_AM62A7
+   bool "TI's K3 based AM62A7 SoC Family Support"
+
+config SOC_K3_AM642
+   bool "TI's K3 based AM642 SoC Family Support"
+
 config SOC_K3_AM654
bool "TI's K3 based AM654 SoC Family Support"
 
@@ -13,15 +22,6 @@ config SOC_K3_J721E
 config SOC_K3_J721S2
bool "TI's K3 based J721S2 SoC Family Support"
 
-config SOC_K3_AM642
-   bool "TI's K3 based AM642 SoC Family Support"
-
-config SOC_K3_AM625
-   bool "TI's K3 based AM625 SoC Family Support"
-
-config SOC_K3_AM62A7
-   bool "TI's K3 based AM62A7 SoC Family Support"
-
 endchoice
 
 if SOC_K3_J721E
-- 
2.34.1



[PATCH v8 00/16] Introduce initial TI's J784S4 and AM69 support

2024-01-19 Thread Apurva Nandan
Hello Everyone!

This series will introduce basic support (SD and UART) support for Texas
Instruments J784S4 EVM.

The J784S4 SoC device tree patches are taken from kernel patch submissions
and will be updated as they are accepted and merged to the kernel tree.
All other patches are specific to SPL and u-boot and do not have
dependency on other trees. Appreciate a review for acceptance to u-boot
tree.

Here are some of the salient features of the J784S4 automotive grade
application processor:

The J784S4 SoC belongs to the K3 Multicore SoC architecture
platform, providing advanced system integration in automotive,
ADAS and industrial applications requiring AI at the network edge.
This SoC extends the K3 Jacinto 7 family of SoCs with focus on
raising performance and integration while providing interfaces,
memory architecture and compute performance for multi-sensor, high
concurrency applications.

Some highlights of this SoC are:
* Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs,
  4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for
  deep learning and CNN.
* 3D GPU: Automotive grade IMG BXS-4-64 MC1
* Vision Processing Accelerator (VPAC) with image signal processor and Depth
  and Motion Processing Accelerator (DMPAC)
* Three CSI2.0 4L RX plus two CSI2.0 4L TX, two DSI Tx, one eDP/DP and one
  DPI interface.
* Integrated gigabit ethernet switch, up to 8 ports (TDA4VH), two ports
  support 10Gb USXGMII; Two 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role
  device subsystems, Up to 20 MCANs, among other peripherals.

See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022)
for further details: http://www.ti.com/lit/zip/spruj52

In addtion, the J784S4 EVM board is designed for TI J784S4 SoC. It
supports the following interfaces:
* 32 GB DDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode
* x1 Input Audio Jack, x1 Output Audio Jack
* x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port
* x2 4L PCIe connector
* x1 UHS-1 capable micro-SD card slot
* 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash,
  UFS flash.
* x6 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin User Expansion Connector
* x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector
* x1 15-pin CSI header
* x6 MCAN instances

Schematics: https://www.ti.com/lit/zip/sprr458

eMMC UDA moode bootlog: 
https://gist.githubusercontent.com/apurvanandan1997/3cffada252d50a8aa0c00a91f1f2f856/raw/

Note: This series is dependent on the following series for removing findfdt env:
https://lore.kernel.org/u-boot/20240109191506.3820908-1...@ti.com/

Sync-up for PATCH #4 is posted on Linux:
https://lore.kernel.org/linux-arm-kernel/20240119171619.3759205-1-a-nan...@ti.com/

Changes in v8:
1) Squashed Linux am69-sk and j784s4-evm dts patches into one
2) Sorted config addition of SoC in arm/mach-K3/Kconfig
3) Updated commit messages according to the reviews
4) Removed #inlcude 
5) Removed k3_mmc_stop_clock and k3_mmc_restart_clock
6) Moved board_init_f logic to separate smaller functions
7) Removed J784S4 EVM specific Kconfig options in j784s4_int.c
8) Cleaned up emmc boot flow based on commit 
66459346463439c72f84cfd1f985496b8a6142d8
9) Removed the dependency of findfdt and updated to ti_set_fdt_env
10) Updated copyright messages
11) Did cleanup/formatting of yaml files, removing linting errors
12) Removed k3-am69-sk specific things from k3-j784s4-binman.dtsi
13) Changed OF_LIST to a single dtb
14) Added bootph-all tag in EVM and SK dts instead of u-boot.dtsi
15) Trimmed the defconfig files to minimal
16) Merged the MAINTAINER file in right patches
17) Updated OpenOCD tag in U-Boot doc
18) And fixed other formatting mistakes.

Link to v7:
https://lore.kernel.org/u-boot/20231219191537.4039361-1-a-nan...@ti.com/

Changes in v7:
1) Moved to unified memory map in arm64-mmu.c based on
   https://lore.kernel.org/all/20231128170528.407707-1-...@ti.com/
2) Used ARRAY_SIZE in clk-data.c and dev-data.c
3) Removed I2C board detect from j784s4_init.c
4) Rebased to latest next

Link to v6:
https://lore.kernel.org/all/20231206123753.1486031-1-a-nan...@ti.com/

Changes in v6:
1) Move bootph-all of memory node to u-boot.dtsi
2) Used a while loop for DRAM controller init, instead of hard-coding for 4 DRAM
3) Fixed build error by adding board/ti/j784s4/Kconfig
4) Trimmed out j784s4_evm.h
5) Fixed checkpatch warnings

Link to v5:
https://patchwork.ozlabs.org/project/uboot/cover/20231130115552.3580995-1-a-nan...@ti.com/

Changes in v5:
1) Incorporated Andrew Davis' "Move R5 specific code into new r5/ directory" and
   "Move board selection to mach-k3" series changes.
2) Incorporated Neha Francis' "Move to using templated FITs" series changes.
3) Synced device tree files with Linux v6.7-rc1
4) Changed ti_mmc to mmc1 target from bootstd
5) Updated doc based on review comments
6) Removed 

Re: [PATCH v1] net: sun8i-emac: Add support for fixed-link phy

2024-01-19 Thread Andre Przywara
On Tue, 16 Jan 2024 19:58:56 +0300
Maxim Kiselev  wrote:

Hi Maxim,

> вт, 16 янв. 2024 г. в 03:18, Andre Przywara :
> >
> > On Thu, 15 Jun 2023 00:44:06 +0300
> > Maxim Kiselev  wrote:
> >
> > Hi Maxim,
> >  
> > > From: Maksim Kiselev 
> > >
> > > Based on dt-specs fixed-link doesn't require phy-handle to be used.  
> >
> > Do you have such a board?  
> 
> Yes, I had a custom board with T113 SoC which has fixed phy eth.

So just to clarify: this board connected something like a switch directly
to the MAC, just using RMII/RGMII? And then you have a fixed-phy node in
the DT, detailing the speed and duplex parameters? Matching the fixed-phy
node description in ethernet-controller.yaml? And drivers/net/phy/fixed.c
takes care of parsing that?

> > And where is that written down? I don't see
> > it explicitly mentioned as optional in ethernet-controller.yaml or in
> > the DT spec PDF.  
> 
> Sorry for that commit description. I just found the similar commit, that
> fixes the same problem for zynq_gem
> 3888c8d1979289efe685fe29276aed4d4b685975 ("net: zynq_gem: Add support for
> fixed-link phy") and copied the description from there.
> 
> > The sun8i EMAC binding lists phy-handle as required,
> > so that would need to be relaxed there then.  
> 
> Oh, indeed. So it will require to send dt-binding changes to Linux first...
> 
> Therefore, I think we can live without fixed-phy support for sun8i EMAC.
> At least until some device with such a configuration appears on the
> market :)

Well, I am fine with that patch if it fixes a problem for you. It looks
like requiring the phy-handle property is too strict, and just needs to be
relaxed in the binding. If I see this correctly, the driver would still
accept every valid DT, by today's and future bindings?

If you could just confirm my above assumptions, and maybe send a v2 with an
amended commit message, I would be happy to merge that patch.

Cheers,
Andre

> > > Fix driver to only read phy related setting when phy-handle is found.  
> >
> > The patch itself looks fine, we already specify -1 as the default when
> > the PHY DT node does not contain a reg property, so that looks like it
> > would work.
> >
> > Cheers,
> > Andre
> >  
> > > Signed-off-by: Maksim Kiselev 
> > > ---
> > >  drivers/net/sun8i_emac.c | 7 ++-
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > index 04c3274fbe..0e339d69e0 100644
> > > --- a/drivers/net/sun8i_emac.c
> > > +++ b/drivers/net/sun8i_emac.c
> > > @@ -834,11 +834,8 @@ static int sun8i_emac_eth_of_to_plat(struct udevice 
> > > *dev)
> > >   priv->use_internal_phy = false;
> > >
> > >   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "phy-handle");
> > > - if (offset < 0) {
> > > - debug("%s: Cannot find PHY address\n", __func__);
> > > - return -EINVAL;
> > > - }
> > > - priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
> > > + if (offset >= 0)
> > > + priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", 
> > > -1);
> > >
> > >   pdata->phy_interface = dev_read_phy_mode(dev);
> > >   debug("phy interface %d\n", pdata->phy_interface);  
> >  
> 
> Best wishes,
> Maksim



[PATCH] wandboard: Convert to watchdog driver model

2024-01-19 Thread Fabio Estevam
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.

Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi | 10 ++
 configs/wandboard_defconfig|  3 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
index 46c4b3b31f4a..80921e80123f 100644
--- a/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
@@ -6,4 +6,14 @@
aliases {
mmc0 = 
};
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   bootph-pre-ram;
+   };
+};
+
+ {
+   bootph-pre-ram;
 };
diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
index 168e2f086008..e9deab38038f 100644
--- a/configs/wandboard_defconfig
+++ b/configs/wandboard_defconfig
@@ -75,6 +75,8 @@ CONFIG_DM_PMIC_PFUZE100=y
 CONFIG_SCSI=y
 CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_USB=y
 CONFIG_VIDEO=y
@@ -88,3 +90,4 @@ CONFIG_IMX_HDMI=y
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
 CONFIG_BMP_16BPP=y
+CONFIG_IMX_WATCHDOG=y
-- 
2.34.1



Re: [PULL] Pull request for u-boot master / v2024.04 = u-boot-stm32-20240119

2024-01-19 Thread Tom Rini
On Fri, Jan 19, 2024 at 05:59:07PM +0100, Patrice CHOTARD wrote:

> Hi Tom
> 
> Please pull the STM32 related patches for u-boot/master, v2024.04: 
> u-boot-stm32-20240119
> 
> CI status: 
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/19379
> 
> The following changes since commit f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3:
> 
>   Revert "test: hush: dollar: fix bugous behavior" (2024-01-18 11:38:25 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-stm.git 
> tags/u-boot-stm32-20240119
> 
> for you to fetch changes up to 8a4d098bb0859b3a26c9e1100ed08d7bd1f8ed30:
> 
>   stm32mp2: Fix CONFIG_STM32MP25X flag usage (2024-01-19 15:49:20 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] headers: don't depend on errno.h being available

2024-01-19 Thread Tom Rini
On Thu, Jan 18, 2024 at 07:10:47PM +0100, max.oss...@gmail.com wrote:

> From: Max Krummenacher 
> 
> These headers follow the pattern:
> 
> | #if CONFIG_IS_ENABLED(FANCY_FEATURE)
> |   void foo(void);
> | #else
> |   static inline void foo(void) { return -ENOSYS; }
> | #endif
> 
> In the #else path ENOSYS is used, however linux/errno.h is not included.
> If errno.h has not been included already the compiler errors out even
> if the inline function is not referenced.
> 
> Make those headers self contained.
> 
> Signed-off-by: Max Krummenacher 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


[PULL] Pull request for u-boot master / v2024.04 = u-boot-stm32-20240119

2024-01-19 Thread Patrice CHOTARD
Hi Tom

Please pull the STM32 related patches for u-boot/master, v2024.04: 
u-boot-stm32-20240119

CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/19379

The following changes since commit f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3:

  Revert "test: hush: dollar: fix bugous behavior" (2024-01-18 11:38:25 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-stm.git 
tags/u-boot-stm32-20240119

for you to fetch changes up to 8a4d098bb0859b3a26c9e1100ed08d7bd1f8ed30:

  stm32mp2: Fix CONFIG_STM32MP25X flag usage (2024-01-19 15:49:20 +0100)


Add CMDLINE dependecy for CMD_STM32KEY

STM32MP1:
-
Set stdio to serial on DH STM32MP15xx DHSOM
Fix reset for usart1 in scmi configuration

STM32MP2:
-
Add BSEC and OTP support for STM32MP25
Fix CONFIG_STM32MP25X flag usage


Marek Vasut (1):
  ARM: stm32: Set stdio to serial on DH STM32MP15xx DHSOM

Patrice Chotard (3):
  ARM: dts: stm32: Fix reset for usart1 in scmi configuration
  stm32mp: add setup_serial_number for stm32mp25
  stm32mp2: Fix CONFIG_STM32MP25X flag usage

Patrick Delaunay (13):
  arm64: dts: st: add bsec support to stm32mp25
  stm32mp: bsec: add driver data
  stm32mp: bsec: add support of stm32mp25
  configs: stm32mp25: add support of fuse command
  stm32mp: add soc.c file
  smt32mp: add setup_mac_address for stm32mp25
  stm32mp: stm32prog: add support of stm32mp25
  stm32mp: activate the command stboard for stm32mp25 boards
  board: st: stm32mp2: add checkboard
  board: st: stm32mp2: display the board identification
  arm: Rename STM32MP13x
  arm: Rename STM32MP15x
  stm32mp: Add dependencies on CMDLINE for command stm32key

Yann Gautier (1):
  arm: stm32mp: add Rev.B support for STM32MP25

 arch/arm/dts/Makefile   |   4 ++--
 arch/arm/dts/stm32mp15-scmi-u-boot.dtsi |   2 +-
 arch/arm/dts/stm32mp15-u-boot.dtsi  |   2 +-
 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi|   4 ++--
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi|   4 ++--
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi|   4 ++--
 arch/arm/dts/stm32mp25-u-boot.dtsi  |   4 
 arch/arm/dts/stm32mp251.dtsi|  16 
 arch/arm/mach-stm32mp/Kconfig   |   9 +
 arch/arm/mach-stm32mp/Kconfig.13x   |   4 ++--
 arch/arm/mach-stm32mp/Kconfig.15x   |   6 +++---
 arch/arm/mach-stm32mp/Makefile  |   5 +++--
 arch/arm/mach-stm32mp/bsec.c|  45 
+
 arch/arm/mach-stm32mp/cmd_stm32key.c|  20 ++--
 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h |  12 ++--
 arch/arm/mach-stm32mp/include/mach/stm32.h  |  24 +---
 arch/arm/mach-stm32mp/include/mach/sys_proto.h  |   1 +
 arch/arm/mach-stm32mp/soc.c | 118 
++
 arch/arm/mach-stm32mp/stm32mp1/Makefile |   4 ++--
 arch/arm/mach-stm32mp/stm32mp1/cpu.c|  96 
+---
 arch/arm/mach-stm32mp/stm32mp1/fdt.c|  10 +-
 arch/arm/mach-stm32mp/stm32mp2/cpu.c|  14 +++---
 arch/arm/mach-stm32mp/stm32mp2/stm32mp25x.c |   3 +++
 board/st/common/Kconfig |   2 +-
 board/st/common/cmd_stboard.c   |   2 ++
 board/st/stm32mp1/Kconfig   |   4 ++--
 board/st/stm32mp1/stm32mp1.c|   6 +++---
 board/st/stm32mp2/stm32mp2.c|  37 
+
 configs/stm32mp13_defconfig |   4 ++--
 configs/stm32mp15_basic_defconfig   |   2 +-
 configs/stm32mp15_defconfig |   2 +-
 configs/stm32mp15_trusted_defconfig |   4 ++--
 configs/stm32mp25_defconfig |   1 +
 drivers/clk/stm32/Kconfig   |   4 ++--
 include/configs/stm32mp15_dh_dhsom.h|  11 +++
 35 files changed, 307 insertions(+), 183 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/soc.c


Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Jens Maus


> Am 19.01.2024 um 17:29 schrieb Ivan T. Ivanov :
> 
>> So you say with your own u-boot.bin you see serial U-Boot output after that 
>> „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the 
>> UART on the GPIO header?
>> 
> 
> Yes :-) See attached log file.

Really strange that in your case U-Boot seems to come up nicely and outputs 
something on the debug UART. Here definitely not. And the only difference in 
the rpi boot loader log outputs I could spot between yours and mine is:

— cut here —
--- uboot2.log  2024-01-19 17:36:18.099674743 +0100
+++ uboot1.log  2024-01-19 17:33:06.794258533 +0100
@@ -1,13 +1,13 @@
-RPi: BOOTSYS release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
-BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 
boardrev d04170 stc 930201
+RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
+BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede 
boardrev c04170 stc 815886
 AON_RESET: 0003 PM_RSTS 1000
 RP1_BOOT chip ID: 0x20001927
 PM_RSTS: 0x1000
 part  reset_info 
 PMIC reset-event  rtc  alarm  enabled 0
 uSD voltage 3.3V
-Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 4267
-DDR 4267 1 0 64 152
+Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit 4267
+DDR 4267 1 0 32 152
 RP1_BOOT chip ID: 0x20001927
 
 RP1_BOOT chip ID: 0x20001927
@@ -17,18 +17,17 @@
 PCIe scan 1de4:0001
 RP1_CHIP_INFO 20001927
 
-RPi: BOOTLOADER release VERSION:30cc5f37 DATE: 2024/01/05 TIME: 15:57:40
-BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1704470260 serial 9127ae99 
boardrev d04170 stc 3949421
+RPi: BOOTLOADER release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
+BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede 
boardrev c04170 stc 3726990
 AON_RESET: 0003 PM_RSTS 1000
-M.2 PCIe HAT not detected.
 usb_pd_init status 1
 Boot mode: SD (01) order f4
 SD HOST: 2 CTL0: 0x0080 BUS: 40 Hz actual: 390625 HZ div: 512 
(256) status: 0x1fff delay: 276
 SD HOST: 2 CTL0: 0x00800f00 BUS: 40 Hz actual: 390625 HZ div: 512 
(256) status: 0x1fff delay: 276
-OCR c0ff8000 [310]
-CID: 00035344534536344780519441cb0123
-CSD: 400e00325b590001dbd37f800a404000
-SD: bus-width: 4 spec: 2 SCR: 0x02458443 0x
+OCR c0ff8000 [118]
+CID: 00035344534e33324780fa570bda0169
+CSD: 400e00325b59edb07f800a40
+SD: bus-width: 4 spec: 2 SCR: 0x02358483 0x
 SD HOST: 2 CTL0: 0x00800f04 BUS: 5000 Hz actual: 5000 HZ div: 
4 (2) status: 0x1fff delay: 2
 MBR: 0x2000,  131072 type: 0x0c
 MBR: 0x00022000, 1024000 type: 0x82
@@ -39,7 +38,6 @@
 rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
 FAT16 clusters 32695
 [sdcard] autoboot.txt not found
-Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0
 Trying partition: 0
 type: 16 lba: 8192 'mkfs.fat' '  V   ^ ' clusters 32695 (4)
 rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
@@ -52,6 +50,7 @@
 Read bcm2712-rpi-5-b.dtb bytes79357 hnd 0x139f
 dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
+PM_RSTS 1000
 Selecting USB low current limit
 
 NOTICE:  BL31: v2.6(release):v2.6-239-g2a9ede0bd
— cut here —

So lets see if after you updated to a more recent rpi eeprom U-boot is still 
able to boot…

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/



Re: Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Ivan T. Ivanov
On 01-19 17:12, Jens Maus wrote:
> >> 
> >> On the HDMI port, right? But what about the serial UART output? 
> > 
> > Yes, I can see serial output from U-Boot. I am using one of these
> > simple USB<->UART cables. You can see serial output when you boot
> > with RPiOS, when you use "Raspberry Pi Debug Probe”, right?
> 
> Yes, when booting up RPiOS I can first see the same serial debug output 
> regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then 
> RPiOS comes up and in the end I get an interactive serial console login 
> "raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that 
> special UART port on the rpi5 pcb.
> 

Yeah, I don't know why I asked even though I saw those messages in your log.

> So you say with your own u-boot.bin you see serial U-Boot output after that 
> „NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART 
> on the GPIO header?
> 

Yes :-) See attached log file.

Regards,
Ivan

RPi: BOOTSYS release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede 
boardrev c04170 stc 815886
AON_RESET: 0003 PM_RSTS 1000
RP1_BOOT chip ID: 0x20001927
PM_RSTS: 0x1000
part  reset_info 
PMIC reset-event  rtc  alarm  enabled 0
uSD voltage 3.3V
Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit 4267
DDR 4267 1 0 32 152
RP1_BOOT chip ID: 0x20001927

RP1_BOOT chip ID: 0x20001927
RP1_BOOT: fw size 25968
PCI2 init
PCI2 reset
PCIe scan 1de4:0001
RP1_CHIP_INFO 20001927

RPi: BOOTLOADER release VERSION:30de0ba5 DATE: 2023/10/30 TIME: 16:45:10
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1698684310 serial 3c533ede 
boardrev c04170 stc 3726990
AON_RESET: 0003 PM_RSTS 1000
usb_pd_init status 1
Boot mode: SD (01) order f4
SD HOST: 2 CTL0: 0x0080 BUS: 40 Hz actual: 390625 HZ div: 512 
(256) status: 0x1fff delay: 276
SD HOST: 2 CTL0: 0x00800f00 BUS: 40 Hz actual: 390625 HZ div: 512 
(256) status: 0x1fff delay: 276
OCR c0ff8000 [118]
CID: 00035344534e33324780fa570bda0169
CSD: 400e00325b59edb07f800a40
SD: bus-width: 4 spec: 2 SCR: 0x02358483 0x
SD HOST: 2 CTL0: 0x00800f04 BUS: 5000 Hz actual: 5000 HZ div: 4 
(2) status: 0x1fff delay: 2
MBR: 0x2000,  131072 type: 0x0c
MBR: 0x00022000, 1024000 type: 0x82
MBR: 0x0011c000,10321887 type: 0x83
MBR: 0x,   0 type: 0x00
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V   ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
[sdcard] autoboot.txt not found
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' '  V   ^ ' clusters 32695 (4)
rsc 4 fat-sectors 128 root dir cluster 1 sectors 32 entries 512
FAT16 clusters 32695
Read config.txt bytes 3046 hnd 0x123c
Read ubootconfig.txt bytes   35 hnd 0x468
[sdcard] extraconfig.txt not found
[sdcard] pieeprom.upd not found
usb_max_current_enable default 0 max-current 900
Read bcm2712-rpi-5-b.dtb bytes79357 hnd 0x139f
dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
PM_RSTS 1000
Selecting USB low current limit

NOTICE:  BL31: v2.6(release):v2.6-239-g2a9ede0bd
NOTICE:  BL31: Built : 14:26:57, Jun 22 2023


U-Boot 2024.01-00778-ga7376eff69-dirty (Jan 19 2024 - 07:17:48 +0200)

DRAM:  fdtdec_setup_memory_banksize: DRAM Bank #0: start = 0x0, size = 
0x3fc0
fdtdec_setup_memory_banksize: DRAM Bank #1: start = 0x4000, size = 
0xc000
1020 MiB (effective 4 GiB)
mbox: Header response code invalid
RPI 5 Model B (0xc04170)
Core:  22 devices, 12 uclasses, devicetree: board
MMC:   mmc@fff000: 0, mmc@110: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
mbox: Header response code invalid
bcm2835: Could not query MAC address
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0
U-Boot>

Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Jens Maus


> Am 19.01.2024 um 15:24 schrieb Ivan T. Ivanov :
> 
>> On 19 Jan 2024, at 16:08, Jens Maus  wrote:
>> 
>> On the HDMI port, right? But what about the serial UART output? 
> 
> Yes, I can see serial output from U-Boot. I am using one of these
> simple USB<->UART cables. You can see serial output when you boot
> with RPiOS, when you use "Raspberry Pi Debug Probe”, right?

Yes, when booting up RPiOS I can first see the same serial debug output 
regarding the rpi boot loader until the same „NOTICE: BL31: …“ lines. Then 
RPiOS comes up and in the end I get an interactive serial console login 
"raspberrypi login:“ prompt on the RaspberryPi Debug Probe connection to that 
special UART port on the rpi5 pcb.

So you say with your own u-boot.bin you see serial U-Boot output after that 
„NOTICE: BL31: …“ lines? On that special UART port on the rpi5 or on the UART 
on the GPIO header?

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/



Re: [PATCH] getchar(): Correct usage

2024-01-19 Thread Tom Rini
On Tue, Jan 09, 2024 at 05:57:16PM -0500, Tom Rini wrote:

> The function getchar() returns an 'int' and not a 'char'. Coverity notes
> that "Assigning the return value of getchar to char ... truncates its value."
> and so for the most part we can resolve this easily by using 'int' as
> intended, and often used throughout the codebase. A few places are not
> so simple and would require further re-architecting of the code in order
> to change this, so we leave them be.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] cmd: license: Add CONFIG_GZIP dependency

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 12:58:19PM +, Ivan Orlov wrote:

> 'License' command processing code could be successfully compiled only
> when CONFIG_GZIP option is enabled, otherwise it can't find the 'gunzip'
> function definition (it is defined in lib/gunzip.c).
> 
> Add CONFIG_GZIP dependency to 'license' command config option in the
> corresponding Kconfig.
> 
> Signed-off-by: Ivan Orlov 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] cmd: nvedit: Fix typo in 'illegal character' error

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 05:20:45PM +, Ivan Orlov wrote:

> Fix a typo: add a space after the single quote in 'illegal character'
> error message in 'env set' command
> 
> Signed-off-by: Ivan Orlov 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] image-host: refactor and protect for very long filenames

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 03:24:30PM +0100, Hugo Cornelis wrote:

> This patch adds a function fit_image_read_key_iv_data that checks the
> return value of snprintf and allows to generate a sensible error
> message when generating binary images using filenames that are too
> long for the OS to handle.
> 
> This is especially relevant for automated builds such as Buildroot and
> Yocto builds.
> 
> Signed-off-by: Hugo Cornelis 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4] drivers: pci: Fix dm_pci_map_bar() to support 64b BARs

2024-01-19 Thread Tom Rini
On Wed, Jan 10, 2024 at 04:59:02AM +, Moritz Fischer wrote:

> This enables 64b BARs if CONFIG_SYS_PCI_64BIT is enabled.
> 
> Reviewed-by: Philip Oberfichtner 
> Reviewed-by: Simon Glass 
> Signed-off-by: Moritz Fischer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 RESEND 2/2] nvme: Update nvme_scan_namespace to keep trying on busy

2024-01-19 Thread Tom Rini
On Wed, Jan 10, 2024 at 05:04:48AM +, Moritz Fischer wrote:

> A busy controller shouldn't be game-over for all controllers,
> so keep trying on hitting -EBUSY.
> 
> This change brings the actual behavior of the routine in line
> with what the descriptions says.
> 
> Fixes: 982388eaa991 ("nvme: Add NVM Express driver support")
> Reviewed-by: Simon Glass 
> Signed-off-by: Moritz Fischer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 RESEND 1/2] nvme: Fix error code and log to indicate busy

2024-01-19 Thread Tom Rini
On Wed, Jan 10, 2024 at 05:04:47AM +, Moritz Fischer wrote:

> Return -EBUSY if controller is found busy rather than -ENOMEM
> and update the error message accordingly.
> 
> Fixes: 982388eaa991 ("nvme: Add NVM Express driver support")
> Reviewed-by: Simon Glass 
> Signed-off-by: Moritz Fischer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] iommu: dont fail silently

2024-01-19 Thread Tom Rini
On Thu, Jan 04, 2024 at 05:12:22PM +, Caleb Connolly wrote:

> When attempting to probe a device which has an associated IOMMU, if the
> IOMMU device can't be found (no driver, disabled driver, driver failed
> to probe, etc) then we currently fail to probe the device with no
> discernable error.
> 
> If we fail to hook the device up to its IOMMU, we should make sure that
> the user knows about it. Write some better error messages for
> dev_iommu_enable() to facilitate this.
> 
> Signed-off-by: Caleb Connolly 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] lib: rsa: Allow legacy URI specification without "pkcs11:"

2024-01-19 Thread Tom Rini
On Fri, Jan 05, 2024 at 03:08:04PM +0100, Csókás Bence wrote:

> But emit a warning for it. Then we can remove support when
> everyone had time to update their scripts, docs, CI etc.
> 
> Fixes: ece85cc020 rsa: use pkcs11 uri as defined in rfc7512
> 
> Signed-off-by: Csókás Bence 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] lib: rsa: Fix PKCS11 URI if one is not given in `keydir`

2024-01-19 Thread Tom Rini
On Fri, Jan 05, 2024 at 03:08:03PM +0100, Csókás Bence wrote:

> If `keydir` is not present, we need to build a PKCS11 URI
> from just the key name. In this case, we *do* need 'pkcs11:'
> 
> Fixes: ece85cc020 rsa: use pkcs11 uri as defined in rfc7512
> 
> Signed-off-by: Csókás Bence 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] test: Skip cleanup test if not built out of tree

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 10:11:00PM +0100, Tobias Deiminger wrote:

> 42c0e5bb054d ("test: Find leftovers after clean/mrproper") assumes out
> of tree builds. test_clean and test_mrproper fail if the assumption
> isn't met.
> 
> However there are valid scenarios where tests run with in source builds
> (i.e., test.py --build-dir=.).
> 
> Automatically skip cleanup tests in such scenarios to prevent false
> positives.
> 
> Signed-off-by: Tobias Deiminger 
> Reviewed-by: Harald Seiler 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] test/py: bootstage: Add test for bootstage command

2024-01-19 Thread Tom Rini
On Tue, Jan 09, 2024 at 02:39:57PM +0530, Love Kumar wrote:

> Add test cases for bootstage command to print the bootstage report, to
> stash the data into memory and to unstash the data from memory.
> 
> Signed-off-by: Love Kumar 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] get_maintainer.pl: slightly modify penguin_chief

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 05:51:27PM +0100, Anthony Loiseau wrote:

> From: Anthony Loiseau 
> 
> Penguin chiefs are actually stripped out from get_maintainer results unless
> --git-chief-penguins is provided, which appends them to all results instead.
> 
> This is a issue for U-Boot since Tom Rini (penguin chief) is also maintainer
> of some sub-trees ("ARM", "ARM TI" and "THE REST").
> 
> Hopefully, this match is performed case-senditive over name and email,
> therefore upper-casing Tom Rini last name workarounds the issue.
> 
> Important note: This also fixes "THE REST" catch all section resulting
> in Tom Rini listed as (maintainer:THE REST) for all files. Hope there is not
> too much developers scripting their patch email header from get_maintainer.pl
> output, otherwise Tom Rini may be flooded.
> 
> Cc: Tom Rini 
> Signed-off-by: Anthony Loiseau 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] smbios: fix matching issues for table types

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 04:39:36PM +0200, Ilias Apalodimas wrote:

> commit 738b34668f28 ("smbios: Fallback to the default DT if sysinfo nodes are 
> missing")
> allowed the code to fallback and fill in SMBIOS tables with properties
> from the compatible and product nodes of the DT, in case the
> 'smbios,sysinfo' node is missing.
> That works fine for Type1/2 tables, but for other types we need to
> match the smbios,sysinfo subnode name as well. So add it to the
> smbios_ctx and check it during the sysinfo <-> DT mathcing
> 
> Signed-off-by: Ilias Apalodimas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] smbios: shorten sysinfo_str declarations and use

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 04:39:35PM +0200, Ilias Apalodimas wrote:

> sysinfo_str is a bit too long and makes indentation weird. Shorten it
> to si_str.
> 
> Signed-off-by: Ilias Apalodimas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] smbios: buffer overflow when zeroing entry point

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 07:34:08AM +0100, Heinrich Schuchardt wrote:

> A SMBIOS 3 entry point has a different length than an SMBIOS 2.1 entry
> point.
> 
> Fixes: 70924294f375 ("smbios: Use SMBIOS 3.0 to support an address above 4GB")
> Fixes: 1c5f6fa3883d ("smbios: Drop support for SMBIOS2 tables")
> Addresses-Coverity-ID: 477212 ("Wrong sizeof argument")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Ilias Apalodimas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arch: mach-k3: Fix incorrect mapping of higher DDR addresses as device memory

2024-01-19 Thread Tom Rini
On Tue, Jan 09, 2024 at 02:15:51PM +0530, Sekhar Nori wrote:

> Entry for physical address 0x5 in memory map table for MMU
> configuration is spilling over and inadvertently making DDR available at
> higher address (above 4GB address space) get mapped as device memory
> (nGnRnE).
> 
> Fix this by adjusting entry size. Tested on AM62A SK. Before this patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 7f34d7ca
> 
> time: 1 minutes, 14.716 seconds
> 
> After patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 7f34d7ca
> 
> time: 2.710 seconds
> 
> Acked-by: Andrew Davis 
> Signed-off-by: Sekhar Nori 
> Reviewed-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] board: ti: am64: Support TMDS64EVM

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 03:16:50PM +0200, Roger Quadros wrote:

> The TMDS64EVM [1] ships with AM64X SR2.0 HS-FS chip
> and a slightly different board name in the board information
> EEPROM header. Support this board.
> 
> [1] https://www.ti.com/tool/TMDS64EVM
> 
> Gets rid of below message at boot
> "Unidentified board claims AM64-EVM in eeprom header"
> 
> Signed-off-by: Roger Quadros 
> Reviewed-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] include: env: ti: add default for do_main_cpsw0_qsgmii_phyinit

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 01:48:49PM +0530, Manorit Chawdhry wrote:

> By default this variable is unset and this causes the test condition to
> fail on devices that don't have this defined. Set a default value for
> this.
> 
>=> boot
>## Error: "main_cpsw0_qsgmii_phyinit" not defined
>[...]
> 
> Fixes: 0d72b0f2f83b ("include: env: ti: ti_common: Run 
> main_cpsw0_qsgmii_phyinit conditionally")
> 
> Signed-off-by: Manorit Chawdhry 
> Reviewed-by: Mattijs Korpershoek 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] include: env: ti: ti_common: Fix a missing semicolon

2024-01-19 Thread Tom Rini
On Mon, Jan 08, 2024 at 01:48:48PM +0530, Manorit Chawdhry wrote:

> Fix a missing semicolon that leads to syntax error while booting j721s2.
> 
> Importing environment from mmc1 ...
> syntax error at 'run'HUSH died!
> 
> Fixes: 0d72b0f2f83b ("include: env: ti: ti_common: Run 
> main_cpsw0_qsgmii_phyinit conditionally")
> 
> Signed-off-by: Manorit Chawdhry 
> Reviewed-by: Mattijs Korpershoek 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2] ARM: imx: Configure GIC clock parent on Data Modul i.MX8M Plus eDM SBC

2024-01-19 Thread Marek Vasut
The CONFIG_SPL_BOARD_INIT lets SPL common code call spl_board_init()
during the SPL start up. On this particular system, spl_board_init()
is used to reconfigure GIC clock parent to PLL2 500M, which is the
configuration expected by the Linux kernel. Enable SPL_BOARD_INIT
and fill in the GIC clock configuration code.

Set GIC clock to 500 MHz for OD VDD_SOC. Kernel driver does not
allow to change it. Should set the clock after PMIC setting done.
Default is 400 MHz (system_pll1_800m with div = 2) set by ROM for
ND VDD_SOC.

Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
V2: Duplicate code comment into commit message
---
 board/data_modul/imx8mp_edm_sbc/spl.c   | 13 +
 configs/imx8mp_data_modul_edm_sbc_defconfig |  1 +
 2 files changed, 14 insertions(+)

diff --git a/board/data_modul/imx8mp_edm_sbc/spl.c 
b/board/data_modul/imx8mp_edm_sbc/spl.c
index a3600c8568a..cc2d253e391 100644
--- a/board/data_modul/imx8mp_edm_sbc/spl.c
+++ b/board/data_modul/imx8mp_edm_sbc/spl.c
@@ -80,6 +80,19 @@ int data_modul_imx_edm_sbc_board_power_init(void)
return 0;
 }
 
+void spl_board_init(void)
+{
+   /*
+* Set GIC clock to 500 MHz for OD VDD_SOC. Kernel driver does not
+* allow to change it. Should set the clock after PMIC setting done.
+* Default is 400 MHz (system_pll1_800m with div = 2) set by ROM for
+* ND VDD_SOC.
+*/
+   clock_enable(CCGR_GIC, 0);
+   clock_set_target_val(GIC_CLK_ROOT, CLK_ROOT_ON | 
CLK_ROOT_SOURCE_SEL(5));
+   clock_enable(CCGR_GIC, 1);
+}
+
 int spl_board_boot_device(enum boot_device boot_dev_spl)
 {
if (boot_dev_spl == SPI_NOR_BOOT)   /* SPI NOR */
diff --git a/configs/imx8mp_data_modul_edm_sbc_defconfig 
b/configs/imx8mp_data_modul_edm_sbc_defconfig
index a55630c1a6d..d29bc986267 100644
--- a/configs/imx8mp_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mp_data_modul_edm_sbc_defconfig
@@ -56,6 +56,7 @@ CONFIG_SPL_MAX_SIZE=0x25000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x96fc00
 CONFIG_SPL_BSS_MAX_SIZE=0x400
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_BOOTROM_SUPPORT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
-- 
2.43.0



Re: [PATCH v2 1/2] board: ti: *-cfg.yaml: Adhere to yamllint rules

2024-01-19 Thread Tom Rini
On Fri, Jan 05, 2024 at 05:09:16PM +0530, Neha Malcom Francis wrote:

> Clean up all configuration files to adhere to yamllint rules.
> 
> Signed-off-by: Neha Malcom Francis 
> Suggested-by: Nishanth Menon 

After fixing more yamllint problems on newly merged platforms,
Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] tools: binman: ti_board_cfg: Check for linting problems

2024-01-19 Thread Tom Rini
On Fri, Jan 05, 2024 at 05:09:17PM +0530, Neha Malcom Francis wrote:

> Use yamllint for checking whether YAML configuration files are adhering
> to default yamllint rules.
> 
> Signed-off-by: Neha Malcom Francis 
> Suggested-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] cmd: bootflow: remove dead code in do_bootflow_cmdline()

2024-01-19 Thread Tom Rini
On Thu, Jan 11, 2024 at 09:14:33AM +0100, Heinrich Schuchardt wrote:

> Checking argc < 3 twice is redundant.
> 
> Addresses-Coverity-ID: 477198 Logically dead code
> Fixes: 921f63e57238 ("bootflow: Allow setting a cmdline arg with no value")
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] boot: superfluous assignment in bootflow_menu_new()

2024-01-19 Thread Tom Rini
On Sun, Jan 07, 2024 at 10:01:07AM +0100, Heinrich Schuchardt wrote:

> ret is assigned a value 0 which is never used but
> is immediately overwritten in the next statement.
> 
> Addresses-Coverity-ID: 453304 ("Unused value")
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] boot: remove dead code in bootflow_check()

2024-01-19 Thread Tom Rini
On Sun, Jan 07, 2024 at 09:43:40AM +0100, Heinrich Schuchardt wrote:

> The 'return 0;' statement is not reachable. Remove it.
> 'else' is superfluous after an if statement with return.
> 
> Addresses-Coverity-ID: 352451 ("Logically dead code")
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [resend PATCH] bootdev: avoid infinite probe loop

2024-01-19 Thread Tom Rini
On Thu, Jan 04, 2024 at 04:03:35PM +, Caleb Connolly wrote:

> Sometimes, when only one bootdev is available, and it fails to probe, we
> end up in an infinite loop calling probe() on the same device over and
> over. With only debug level log output.
> 
> Break the loop if we fail to probe the same device twice in a row, and
> promote the probe failure message to log_warning().
> 
> Signed-off-by: Caleb Connolly 
> Reviewed-by: Simon Glass 
> Reviewed-by: Dragan Simic 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2] ARM: imx: Enable SPL_BOARD_INIT on DH i.MX8M Plus DHCOM

2024-01-19 Thread Marek Vasut
The CONFIG_SPL_BOARD_INIT lets SPL common code call spl_board_init()
during the SPL start up. On this particular system, spl_board_init()
is used to reconfigure GIC clock parent to PLL2 500M, which is the
configuration expected by the Linux kernel. Enable SPL_BOARD_INIT .

Set GIC clock to 500 MHz for OD VDD_SOC. Kernel driver does not
allow to change it. Should set the clock after PMIC setting done.
Default is 400 MHz (system_pll1_800m with div = 2) set by ROM for
ND VDD_SOC.

Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
V2: Duplicate code comment into commit message
---
 configs/imx8mp_dhcom_pdk2_defconfig | 1 +
 configs/imx8mp_dhcom_pdk3_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/imx8mp_dhcom_pdk2_defconfig 
b/configs/imx8mp_dhcom_pdk2_defconfig
index dc482abad85..4f907ce00d0 100644
--- a/configs/imx8mp_dhcom_pdk2_defconfig
+++ b/configs/imx8mp_dhcom_pdk2_defconfig
@@ -54,6 +54,7 @@ CONFIG_SPL_MAX_SIZE=0x26000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x96fc00
 CONFIG_SPL_BSS_MAX_SIZE=0x400
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_BOOTROM_SUPPORT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
diff --git a/configs/imx8mp_dhcom_pdk3_defconfig 
b/configs/imx8mp_dhcom_pdk3_defconfig
index 3442af6f00e..9972e2d96b6 100644
--- a/configs/imx8mp_dhcom_pdk3_defconfig
+++ b/configs/imx8mp_dhcom_pdk3_defconfig
@@ -55,6 +55,7 @@ CONFIG_SPL_MAX_SIZE=0x26000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x96fc00
 CONFIG_SPL_BSS_MAX_SIZE=0x400
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_BOOTROM_SUPPORT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
-- 
2.43.0



Re: Pull request: u-boot-rockchip-20240119

2024-01-19 Thread Tom Rini
On Fri, Jan 19, 2024 at 04:20:23PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the updates for rockchip platform:
> - Add board: rk3328 FriendlyARM NanoPi R2C Plus, rk3588 Turing RK1 SoM;
> - Enable SPI boot for rk3588 and rk3528;
> - Set boot device in SPL as common code;
> - other misc fixes;
> 
> CI:
> https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/19374
> 
> Thanks,
> - Kever
> 
> The following changes since commit f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3:
> 
>   Revert "test: hush: dollar: fix bugous behavior" (2024-01-18 11:38:25 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20240119
> 
> for you to fetch changes up to c16c7ac2fe69f3cebbfc921c5b023dccc12cd198:
> 
>   rockchip: rk3128: remove noop file (2024-01-19 10:57:36 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot

2024-01-19 Thread Nishanth Menon
On 16:05-20240110, Sumit Garg wrote:
[...]
> Prerequisite
> 
> 
> This patch series requires devicetree-rebasing git repo to be added as a
> subtree to the main U-Boot repo via:
> 
> $ git subtree add --prefix dts/upstream \
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
>  \

Please use https://

also what is the baseline? didn't seem to apply on (fails at patch #2):
next f28a77589e75 Merge tag 'dm-next-7jan23' of 
https://source.denx.de/u-boot/custodians/u-boot-dm into next
master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior"

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


Re: [PATCH v2 1/2] part: Add a function to find ESP partition

2024-01-19 Thread mchitale
Hi Heinrich,

On Tue, 2024-01-16 at 17:14 +0100, Heinrich Schuchardt wrote:
> On 16.01.24 14:45, Heinrich Schuchardt wrote:
> > On 16.01.24 13:36, Mayuresh Chitale wrote:
> > > If a disk has an EFI system partition (ESP) then it can be used
> > > to
> > > locate the boot files. Add a function to find the ESP.
> > > 
> > > Signed-off-by: Mayuresh Chitale 
> > > Reviewed-by: Heinrich Schuchardt <
> > > heinrich.schucha...@canonical.com>
> 
> I ran your patches through Gitlab CI and some issues came up:
> 
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/771497
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/771498
> 
> Could you, please, have a look at it.

I looked into the log files below:
https://u-boot.source-pages.denx.de/-/custodians/u-boot-efi/-/jobs/771497/artifacts/test-log.html
https://u-boot.source-pages.denx.de/-/custodians/u-boot-efi/-/jobs/771498/artifacts/test-log.html

If those logs are correct, I think the failure is probably because I
removed fallback to the user provided partition in case the ESP probe
failed for some reason. I think that fallback is required here. 
> 
> Best regards
> 
> Heinrich
> 
> > > ---
> > >   disk/part.c| 16 
> > >   include/part.h | 11 +++
> > >   2 files changed, 27 insertions(+)
> > > 
> > > diff --git a/disk/part.c b/disk/part.c
> > > index 36b88205eca..6b1fbc18637 100644
> > > --- a/disk/part.c
> > > +++ b/disk/part.c
> > > @@ -848,3 +848,19 @@ int part_get_bootable(struct blk_desc *desc)
> > >   return 0;
> > >   }
> > > +
> > > +int part_get_esp(struct blk_desc *desc)
> > > +{
> > > +struct disk_partition info;
> > > +int p;
> > > +
> > > +for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
> > > +int ret;
> > > +
> > > +ret = part_get_info(desc, p, );
> > > +if (!ret && (info.bootable & PART_EFI_SYSTEM_PARTITION))
> > > +return p;
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > diff --git a/include/part.h b/include/part.h
> > > index db34bc6bb7d..30e049c8f19 100644
> > > --- a/include/part.h
> > > +++ b/include/part.h
> > > @@ -690,6 +690,14 @@ int part_get_type_by_name(const char *name);
> > >*/
> > >   int part_get_bootable(struct blk_desc *desc);
> > > +/**
> > > + * part_get_esp() - Find the EFI system partition
> > > + *
> > > + * @desc: Block-device descriptor
> > > + * @Return the EFI system partition, or 0 if there is none
> > 
> > We want to be able to add the include to our API documentation.
> > This 
> > requires adhering to the Sphinx documentation style.
> > 
> > %s/@Return the/Return:/
> > 
> > Cf. 
> > https://www.kernel.org/doc/html/v6.7/doc-guide/kernel-doc.html#function-documentation
> > 
> > Best regards
> > 
> > Heinrich
> > 
> > > + */
> > > +int part_get_esp(struct blk_desc *desc);
> > > +
> > >   #else
> > >   static inline int part_driver_get_count(void)
> > >   { return 0; }
> > > @@ -700,6 +708,9 @@ static inline struct part_driver 
> > > *part_driver_get_first(void)
> > >   static inline bool part_get_bootable(struct blk_desc *desc)
> > >   { return false; }
> > > +static inline bool part_get_esp(struct blk_desc *desc)
> > > +{ return false; }
> > > +
> > >   #endif /* CONFIG_PARTITIONS */
> > >   #endif /* _PART_H */



[PATCH v7 5/8] arm: armv8: save boot arguments

2024-01-19 Thread Raymond Mao
Save boot arguments x[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in V5
- Drop the dependence on OF_BOARD.
Changes in V7
- Exclude the saved_args when BLOBLIST is disabled.

 arch/arm/cpu/armv8/start.S | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 6cc1d26e5e..2a26b1c276 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -370,5 +370,21 @@ ENTRY(c_runtime_cpu_setup)
 ENDPROC(c_runtime_cpu_setup)
 
 WEAK(save_boot_params)
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+   adr x9, saved_args
+   stp x0, x1, [x9]
+   /* Increment the address by 16 bytes for the next pair of values */
+   stp x2, x3, [x9, #16]
+#endif
b   save_boot_params_ret/* back to my caller */
 ENDPROC(save_boot_params)
+
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+.section .data
+.global saved_args
+saved_args:
+   .rept 4
+   .xword 0
+   .endr
+END(saved_args)
+#endif
-- 
2.25.1



[PATCH v7 RESEND 0/8] Handoff bloblist from previous boot stage

2024-01-19 Thread Raymond Mao
This patch set adds/adapts a few bloblist APIs and implements Arm arch
custom function to retrieve the bloblist (aka. Transfer List) from
previous loader via boot arguments when BLOBLIST option is enabled and
all boot arguments are compliant to the register conventions defined
in the Firmware Handoff spec v0.9.

If an arch wishes to have different behaviors for loading bloblist
from the previous boot stage, it is required to implement the custom
function xferlist_from_boot_arg().

V5:
Drop [PATCH v4 8/9] fdt: update the document and Kconfig description.
V6:
Drop [PATCH v5 8/8] fdt: get FDT from bloblist.
V7:
Fixed CI pipeline failures.

Raymond Mao (8):
  bloblist: add API to check the register conventions
  bloblist: check bloblist with specified buffer size
  bloblist: refactor of bloblist_reloc()
  arm: armv7: save boot arguments
  arm: armv8: save boot arguments
  arm: Get bloblist from boot arguments
  bloblist: Load the bloblist from the previous loader
  dts: OF_HAS_PRIOR_STAGE should depend on !BLOBLIST

 arch/arm/cpu/armv7/start.S | 21 ++
 arch/arm/cpu/armv8/start.S | 16 +++
 arch/arm/lib/Makefile  |  2 +
 arch/arm/lib/xferlist.c| 27 
 arch/arm/lib/xferlist.h| 19 +
 common/bloblist.c  | 85 --
 common/board_f.c   |  9 ++--
 dts/Kconfig|  1 +
 include/bloblist.h | 47 +
 test/bloblist.c|  8 ++--
 10 files changed, 195 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/lib/xferlist.c
 create mode 100644 arch/arm/lib/xferlist.h

-- 
2.25.1



[PATCH v7 8/8] dts: OF_HAS_PRIOR_STAGE should depend on !BLOBLIST

2024-01-19 Thread Raymond Mao
When BLOBLIST is enabled, FDT is expected to be from bloblist
carried from previous stage, instead of from OF_BOARD, therefore
only enable OF_HAS_PRIOR_STAGE when BLOBLIST is disabled.

Signed-off-by: Raymond Mao 
---
Changes in V7
- Initial patch .

 dts/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff89..def0e17241 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -121,6 +121,7 @@ config OF_BOARD
 
 config OF_HAS_PRIOR_STAGE
bool
+   depends on !BLOBLIST
help
  Indicates that a prior stage of the firmware (before U-Boot proper)
  makes use of device tree and this board normally boots with that prior
-- 
2.25.1



[PATCH v7 7/8] bloblist: Load the bloblist from the previous loader

2024-01-19 Thread Raymond Mao
During bloblist initialization, load the bloblist via boot arguments
from the previous loader.
If a valid bloblist exists in boot arguments, relocate it into the
fixed bloblist memory region.
If not, fallback to support BLOBLIST_ADDR or BLOBLIST_ALLOC.

Signed-off-by: Raymond Mao 
---
Changes in v4
- Add weak default function.
- Add comments for BLOBLIST_ALLOC.
- Add local debug macro.
- Refine the commit message.
Changes in V5
- Drop the dependence on OF_BOARD.
- Remove local debug macro.

 common/bloblist.c  | 62 --
 include/bloblist.h | 10 
 2 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index c2fd07575f..ad06d7a179 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -487,37 +487,57 @@ int bloblist_reloc(void *to, uint to_size)
return 0;
 }
 
+/*
+ * Weak default function for getting bloblist from boot args.
+ */
+int __weak xferlist_from_boot_arg(ulong __always_unused addr,
+ ulong __always_unused size)
+{
+   return -ENOENT;
+}
+
 int bloblist_init(void)
 {
bool fixed = IS_ENABLED(CONFIG_BLOBLIST_FIXED);
int ret = -ENOENT;
ulong addr, size;
-   bool expected;
-
-   /**
-* We don't expect to find an existing bloblist in the first phase of
-* U-Boot that runs. Also we have no way to receive the address of an
-* allocated bloblist from a previous stage, so it must be at a fixed
+   /*
+* If U-Boot is not in the first phase, an existing bloblist must be
+* at a fixed address.
+*/
+   bool from_addr = fixed && !u_boot_first_phase();
+   /*
+* If U-Boot is in the first phase that an arch custom routine should
+* install the bloblist passed from previous loader to this fixed
 * address.
 */
-   expected = fixed && !u_boot_first_phase();
+   bool from_boot_arg = fixed && u_boot_first_phase();
+
if (spl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
-   expected = false;
+   from_addr = false;
if (fixed)
addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED,
  CONFIG_BLOBLIST_ADDR);
size = CONFIG_BLOBLIST_SIZE;
-   if (expected) {
+
+   if (from_boot_arg)
+   ret = xferlist_from_boot_arg(addr, size);
+   else if (from_addr)
ret = bloblist_check(addr, size);
-   if (ret) {
-   log_warning("Expected bloblist at %lx not found 
(err=%d)\n",
-   addr, ret);
-   } else {
-   /* Get the real size, if it is not what we expected */
-   size = gd->bloblist->total_size;
-   }
-   }
+
+   if (ret)
+   log_warning("Bloblist at %lx not found (err=%d)\n",
+   addr, ret);
+   else
+   /* Get the real size */
+   size = gd->bloblist->total_size;
+
if (ret) {
+   /*
+* If we don't have a bloblist from a fixed address, or the one
+* in the fixed address is not valid. we must allocate the
+* memory for it now.
+*/
if (CONFIG_IS_ENABLED(BLOBLIST_ALLOC)) {
void *ptr = memalign(BLOBLIST_ALIGN, size);
 
@@ -525,7 +545,8 @@ int bloblist_init(void)
return log_msg_ret("alloc", -ENOMEM);
addr = map_to_sysmem(ptr);
} else if (!fixed) {
-   return log_msg_ret("!fixed", ret);
+   return log_msg_ret("BLOBLIST_FIXED is not enabled",
+  ret);
}
log_debug("Creating new bloblist size %lx at %lx\n", size,
  addr);
@@ -538,6 +559,11 @@ int bloblist_init(void)
return log_msg_ret("ini", ret);
gd->flags |= GD_FLG_BLOBLIST_READY;
 
+#ifdef DEBUG
+   bloblist_show_stats();
+   bloblist_show_list();
+#endif
+
return 0;
 }
 
diff --git a/include/bloblist.h b/include/bloblist.h
index 0ae079d62a..7fbdd622bc 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -482,4 +482,14 @@ static inline int bloblist_maybe_init(void)
  */
 int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig);
 
+/**
+ * xferlist_from_boot_arg() - Get bloblist from the boot args and relocate it
+ *   to the specified address.
+ *
+ * @addr: Address for the bloblist
+ * @size: Size of space reserved for the bloblist
+ * Return: 0 if OK, else on error
+ */
+int xferlist_from_boot_arg(ulong addr, ulong size);
+
 #endif /* __BLOBLIST_H */
-- 
2.25.1



[PATCH v7 6/8] arm: Get bloblist from boot arguments

2024-01-19 Thread Raymond Mao
Add arch custom function to get bloblist from boot arguments.
Check whether boot arguments aligns with the register conventions
defined in FW Handoff spec v0.9.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Remove low level code for copying boot arguments.
- Refactor board_fdt_blob_setup() and remove direct access of gd->bloblist.
Changes in v3
- Optimize board_bloblist_from_boot_arg().
Changes in v4
- Move the function as an Arm-arch library instead of a board-specific one.
Changes in V5
- Drop the dependence on OF_BOARD.
- Move external declaration to header file.
- Adjust the position of BLOBLIST in defconfig file.
Changes in V6
- Drop imply OF_HAS_PRIOR_STAGE from qemu-arm.
Changes in V7
- Revert changes in V6.
- Remove BLOBLIST_ settings from qemu_arm64_defconfig.

 arch/arm/lib/Makefile   |  2 ++
 arch/arm/lib/xferlist.c | 25 +
 arch/arm/lib/xferlist.h | 19 +++
 3 files changed, 46 insertions(+)
 create mode 100644 arch/arm/lib/xferlist.c
 create mode 100644 arch/arm/lib/xferlist.h

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index b1bcd37466..67275fba61 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -85,6 +85,8 @@ obj-y += psci-dt.o
 
 obj-$(CONFIG_DEBUG_LL) += debug.o
 
+obj-$(CONFIG_BLOBLIST)  += xferlist.o
+
 # For EABI conformant tool chains, provide eabi_compat()
 ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS)))
 extra-y+= eabi_compat.o
diff --git a/arch/arm/lib/xferlist.c b/arch/arm/lib/xferlist.c
new file mode 100644
index 00..f9c5d88bd4
--- /dev/null
+++ b/arch/arm/lib/xferlist.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+#include 
+#include 
+#include "xferlist.h"
+
+int xferlist_from_boot_arg(ulong addr, ulong size)
+{
+   int ret;
+
+   ret = bloblist_check(saved_args[3], size);
+   if (ret)
+   return ret;
+
+   ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
+ saved_args[1]);
+   if (ret)
+   return ret;
+
+   return bloblist_reloc((void *)addr, size);
+}
diff --git a/arch/arm/lib/xferlist.h b/arch/arm/lib/xferlist.h
new file mode 100644
index 00..60d79c1a8e
--- /dev/null
+++ b/arch/arm/lib/xferlist.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */
+/*
+ * Copyright (C) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+
+#ifndef _XFERLIST_H_
+#define _XFERLIST_H_
+
+/*
+ * Boot parameters saved from start.S
+ * saved_args[0]: FDT base address
+ * saved_args[1]: Bloblist signature
+ * saved_args[2]: must be 0
+ * saved_args[3]: Bloblist base address
+ */
+extern unsigned long saved_args[];
+
+#endif /* _XFERLIST_H_ */
-- 
2.25.1



[PATCH v7 5/8] arm: armv8: save boot arguments

2024-01-19 Thread Raymond Mao
Save boot arguments x[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in V5
- Drop the dependence on OF_BOARD.
Changes in V7
- Exclude the saved_args when BLOBLIST is disabled.

 arch/arm/cpu/armv8/start.S | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 6cc1d26e5e..2a26b1c276 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -370,5 +370,21 @@ ENTRY(c_runtime_cpu_setup)
 ENDPROC(c_runtime_cpu_setup)
 
 WEAK(save_boot_params)
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+   adr x9, saved_args
+   stp x0, x1, [x9]
+   /* Increment the address by 16 bytes for the next pair of values */
+   stp x2, x3, [x9, #16]
+#endif
b   save_boot_params_ret/* back to my caller */
 ENDPROC(save_boot_params)
+
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+.section .data
+.global saved_args
+saved_args:
+   .rept 4
+   .xword 0
+   .endr
+END(saved_args)
+#endif
-- 
2.25.1



[PATCH v7 4/8] arm: armv7: save boot arguments

2024-01-19 Thread Raymond Mao
Save boot arguments r[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in v3
- Swap value of r0 with r2.
Changes in v4
- Fix a bug when saving the boot args.
Changes in V5
- Drop the dependence on OF_BOARD.
Changes in V7
- Exclude the saved_args when BLOBLIST is disabled.

 arch/arm/cpu/armv7/start.S | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 69e281b086..91691062c1 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -152,9 +152,30 @@ ENDPROC(c_runtime_cpu_setup)
  *
  */
 WEAK(save_boot_params)
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+   ldr r12, =saved_args
+   /*
+* Intentionally swapping r0 with r2 in order to simplify the C
+* function we use later.
+*/
+   str r2, [r12]
+   str r1, [r12, #4]
+   str r0, [r12, #8]
+   str r3, [r12, #12]
+#endif
b   save_boot_params_ret@ back to my caller
 ENDPROC(save_boot_params)
 
+#if (IS_ENABLED(CONFIG_BLOBLIST))
+.section .data
+.global saved_args
+saved_args:
+   .rept 4
+   .word 0
+   .endr
+END(saved_args)
+#endif
+
 #ifdef CONFIG_ARMV7_LPAE
 WEAK(switch_to_hypervisor)
b   switch_to_hypervisor_ret
-- 
2.25.1



[PATCH v7 3/8] bloblist: refactor of bloblist_reloc()

2024-01-19 Thread Raymond Mao
The current bloblist pointer and size can be retrieved from global
data, so we don't need to pass them from the function arguments.
This change also help to remove all external access of gd->bloblist
outside of bloblist module.

Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- New patch file created for v2.
Changes in v3
- Check the space size before copying the bloblist.
- Add return code of bloblist_reloc().
Changes in v4
- return error code from bloblist_reloc().

 common/bloblist.c  | 10 --
 common/board_f.c   |  9 +++--
 include/bloblist.h |  8 
 test/bloblist.c|  6 ++
 4 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 26b0ba33b1..c2fd07575f 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -472,13 +472,19 @@ void bloblist_show_list(void)
}
 }
 
-void bloblist_reloc(void *to, uint to_size, void *from, uint from_size)
+int bloblist_reloc(void *to, uint to_size)
 {
struct bloblist_hdr *hdr;
 
-   memcpy(to, from, from_size);
+   if (to_size < gd->bloblist->total_size)
+   return -ENOSPC;
+
+   memcpy(to, gd->bloblist, gd->bloblist->total_size);
hdr = to;
hdr->total_size = to_size;
+   gd->bloblist = to;
+
+   return 0;
 }
 
 int bloblist_init(void)
diff --git a/common/board_f.c b/common/board_f.c
index d4d7d01f8f..f4145a2698 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -676,13 +676,10 @@ static int reloc_bloblist(void)
return 0;
}
if (gd->new_bloblist) {
-   int size = CONFIG_BLOBLIST_SIZE;
-
debug("Copying bloblist from %p to %p, size %x\n",
- gd->bloblist, gd->new_bloblist, size);
-   bloblist_reloc(gd->new_bloblist, CONFIG_BLOBLIST_SIZE_RELOC,
-  gd->bloblist, size);
-   gd->bloblist = gd->new_bloblist;
+ gd->bloblist, gd->new_bloblist, gd->bloblist->total_size);
+   return bloblist_reloc(gd->new_bloblist,
+ CONFIG_BLOBLIST_SIZE_RELOC);
}
 #endif
 
diff --git a/include/bloblist.h b/include/bloblist.h
index cc78259e5a..0ae079d62a 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -426,11 +426,11 @@ const char *bloblist_tag_name(enum bloblist_tag_t tag);
  * bloblist_reloc() - Relocate the bloblist and optionally resize it
  *
  * @to: Pointer to new bloblist location (must not overlap old location)
- * @to_size: New size for bloblist (must be larger than from_size)
- * @from: Pointer to bloblist to relocate
- * @from_size: Size of bloblist to relocate
+ * @to_size: New size for bloblist
+ * Return: 0 if OK, -ENOSPC if the new size is small than the bloblist total
+ *size.
  */
-void bloblist_reloc(void *to, uint to_size, void *from, uint from_size);
+int bloblist_reloc(void *to, uint to_size);
 
 /**
  * bloblist_init() - Init the bloblist system with a single bloblist
diff --git a/test/bloblist.c b/test/bloblist.c
index 7dab9addf8..1c60bbac36 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -376,13 +376,12 @@ static int bloblist_test_reloc(struct unit_test_state 
*uts)
 {
const uint large_size = TEST_BLOBLIST_SIZE;
const uint small_size = 0x20;
-   void *old_ptr, *new_ptr;
+   void *new_ptr;
void *blob1, *blob2;
ulong new_addr;
ulong new_size;
 
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0, 0));
-   old_ptr = map_sysmem(TEST_ADDR, TEST_BLOBLIST_SIZE);
 
/* Add one blob and then one that won't fit */
blob1 = bloblist_add(TEST_TAG, small_size, 0);
@@ -394,8 +393,7 @@ static int bloblist_test_reloc(struct unit_test_state *uts)
new_addr = TEST_ADDR + TEST_BLOBLIST_SIZE;
new_size = TEST_BLOBLIST_SIZE + 0x100;
new_ptr = map_sysmem(new_addr, TEST_BLOBLIST_SIZE);
-   bloblist_reloc(new_ptr, new_size, old_ptr, TEST_BLOBLIST_SIZE);
-   gd->bloblist = new_ptr;
+   ut_assertok(bloblist_reloc(new_ptr, new_size));
 
/* Check the old blob is there and that we can now add the bigger one */
ut_assertnonnull(bloblist_find(TEST_TAG, small_size));
-- 
2.25.1



[PATCH v7 2/8] bloblist: check bloblist with specified buffer size

2024-01-19 Thread Raymond Mao
Instead of expecting the bloblist total size to be the same as the
pre-allocated buffer size, practically we are more interested in
whether the pre-allocated buffer size is bigger than the bloblist
total size.

Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- New patch file created for v2.
Changes in v4
- Update function header of bloblist_check().

 common/bloblist.c  | 2 +-
 include/bloblist.h | 9 +
 test/bloblist.c| 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 980b1ddbcb..26b0ba33b1 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -384,7 +384,7 @@ int bloblist_check(ulong addr, uint size)
return log_msg_ret("Bad magic", -ENOENT);
if (hdr->version != BLOBLIST_VERSION)
return log_msg_ret("Bad version", -EPROTONOSUPPORT);
-   if (!hdr->total_size || (size && hdr->total_size != size))
+   if (!hdr->total_size || (size && hdr->total_size > size))
return log_msg_ret("Bad total size", -EFBIG);
if (hdr->used_size > hdr->total_size)
return log_msg_ret("Bad used size", -ENOENT);
diff --git a/include/bloblist.h b/include/bloblist.h
index f7e800f681..cc78259e5a 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -348,12 +348,13 @@ int bloblist_new(ulong addr, uint size, uint flags, uint 
align_log2);
  * bloblist_check() - Check if a bloblist exists
  *
  * @addr: Address of bloblist
- * @size: Expected size of blobsize, or 0 to detect the size
+ * @size: Reserved space size for blobsize, or 0 to use the total size
  * Return: 0 if OK, -ENOENT if the magic number doesn't match (indicating that
- * there problem is no bloblist at the given address), -EPROTONOSUPPORT
+ * there problem is no bloblist at the given address) or any fields for header
+ * size, used size and total size do not match, -EPROTONOSUPPORT
  * if the version does not match, -EIO if the checksum does not match,
- * -EFBIG if the expected size does not match the detected size, -ENOSPC
- * if the size is not large enough to hold the headers
+ * -EFBIG if the reserved space size is small than the total size or total size
+ * is 0
  */
 int bloblist_check(ulong addr, uint size);
 
diff --git a/test/bloblist.c b/test/bloblist.c
index 17d9dd03d0..7dab9addf8 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -207,7 +207,7 @@ static int bloblist_test_checksum(struct unit_test_state 
*uts)
hdr->flags++;
 
hdr->total_size--;
-   ut_asserteq(-EFBIG, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
+   ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
hdr->total_size++;
 
hdr->spare++;
-- 
2.25.1



[PATCH v7 1/8] bloblist: add API to check the register conventions

2024-01-19 Thread Raymond Mao
Add bloblist_check_reg_conv() to check whether the bloblist is compliant
to the register conventions defined in Firmware Handoff specification.
This API can be used for all Arm platforms.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Refactor of bloblist_check_reg_conv().
Changes in v3
- bloblist_check_reg_conv() returns -ENOENT if OF_BOARD is disabled.
Changes in v4
- Add checking of signature register.
Changes in V5
- Drop the dependence on OF_BOARD.

 common/bloblist.c  | 11 +++
 include/bloblist.h | 20 
 2 files changed, 31 insertions(+)

diff --git a/common/bloblist.c b/common/bloblist.c
index 2d373910b6..980b1ddbcb 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -542,3 +542,14 @@ int bloblist_maybe_init(void)
 
return 0;
 }
+
+int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig)
+{
+   if (rzero || rsig != (BLOBLIST_MAGIC | BLOBLIST_REGCONV_VER) ||
+   rfdt != (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0)) {
+   gd->bloblist = NULL;  /* Reset the gd bloblist pointer */
+   return -EIO;
+   }
+
+   return 0;
+}
diff --git a/include/bloblist.h b/include/bloblist.h
index 84fc943819..f7e800f681 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -78,6 +78,13 @@ enum {
BLOBLIST_VERSION= 1,
BLOBLIST_MAGIC  = 0x4a0fb10b,
 
+   /*
+* FIXME:
+* Register convention version should be placed into a higher byte
+* https://github.com/FirmwareHandoff/firmware_handoff/issues/32
+*/
+   BLOBLIST_REGCONV_VER= 1 << 24,
+
BLOBLIST_BLOB_ALIGN_LOG2 = 3,
BLOBLIST_BLOB_ALIGN  = 1 << BLOBLIST_BLOB_ALIGN_LOG2,
 
@@ -461,4 +468,17 @@ static inline int bloblist_maybe_init(void)
 }
 #endif /* BLOBLIST */
 
+/**
+ * bloblist_check_reg_conv() - Check whether the bloblist is compliant to
+ *the register conventions according to the
+ *Firmware Handoff spec.
+ *
+ * @rfdt:  Register that holds the FDT base address.
+ * @rzero: Register that must be zero.
+ * @rsig:  Register that holds signature and register conventions version.
+ * Return: 0 if OK, -EIO if the bloblist is not compliant to the register
+ *conventions.
+ */
+int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig);
+
 #endif /* __BLOBLIST_H */
-- 
2.25.1



[PATCH v7 0/7] Handoff bloblist from previous boot stage

2024-01-19 Thread Raymond Mao
This patch set adds/adapts a few bloblist APIs and implements Arm arch
custom function to retrieve the bloblist (aka. Transfer List) from
previous loader via boot arguments when BLOBLIST option is enabled and
all boot arguments are compliant to the register conventions defined
in the Firmware Handoff spec v0.9.

If an arch wishes to have different behaviors for loading bloblist
from the previous boot stage, it is required to implement the custom
function xferlist_from_boot_arg().

V5:
Drop [PATCH v4 8/9] fdt: update the document and Kconfig description.
V6:
Drop [PATCH v5 8/8] fdt: get FDT from bloblist.
V7:
Fixed CI pipeline failures.

Raymond Mao (8):
  bloblist: add API to check the register conventions
  bloblist: check bloblist with specified buffer size
  bloblist: refactor of bloblist_reloc()
  arm: armv7: save boot arguments
  arm: armv8: save boot arguments
  arm: Get bloblist from boot arguments
  bloblist: Load the bloblist from the previous loader
  dts: OF_HAS_PRIOR_STAGE should depend on !BLOBLIST

 arch/arm/cpu/armv7/start.S | 21 ++
 arch/arm/cpu/armv8/start.S | 16 +++
 arch/arm/lib/Makefile  |  2 +
 arch/arm/lib/xferlist.c| 27 
 arch/arm/lib/xferlist.h| 19 +
 common/bloblist.c  | 85 --
 common/board_f.c   |  9 ++--
 dts/Kconfig|  1 +
 include/bloblist.h | 47 +
 test/bloblist.c|  8 ++--
 10 files changed, 195 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/lib/xferlist.c
 create mode 100644 arch/arm/lib/xferlist.h

-- 
2.25.1



Re: [PATCH] stm32mp2: Fix CONFIG_STM32MP25X flag usage

2024-01-19 Thread Patrice CHOTARD



On 1/19/24 15:45, Patrick DELAUNAY wrote:
> Hi
> 
> On 1/9/24 15:00, Patrice Chotard wrote:
>> "#if" was used instead of "#ifdef"
>>
>> Fixes: 01a701994b05 ("stm32mp2: initial support")
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
>> b/arch/arm/mach-stm32mp/include/mach/stm32.h
>> index 46d469881b3..175f2a88490 100644
>> --- a/arch/arm/mach-stm32mp/include/mach/stm32.h
>> +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
>> @@ -157,7 +157,7 @@ enum forced_boot_mode {
>>   #endif /* __ASSEMBLY__ */
>>   #endif /* CONFIG_STM32MP15X || CONFIG_STM32MP13X */
>>   -#if CONFIG_STM32MP25X
>> +#ifdef CONFIG_STM32MP25X
>>   #define STM32_RCC_BASE    0x4420
>>   #define STM32_TAMP_BASE    0x4601
>>   
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> Patrick
> 
Applied to u-boot-stm32/master

Thanks
Patrice


Re: [PATCH] stm32mp2: Fix CONFIG_STM32MP25X flag usage

2024-01-19 Thread Patrick DELAUNAY

Hi

On 1/9/24 15:00, Patrice Chotard wrote:

"#if" was used instead of "#ifdef"

Fixes: 01a701994b05 ("stm32mp2: initial support")
Signed-off-by: Patrice Chotard 
---

  arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 46d469881b3..175f2a88490 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -157,7 +157,7 @@ enum forced_boot_mode {
  #endif /* __ASSEMBLY__ */
  #endif /* CONFIG_STM32MP15X || CONFIG_STM32MP13X */
  
-#if CONFIG_STM32MP25X

+#ifdef CONFIG_STM32MP25X
  #define STM32_RCC_BASE0x4420
  #define STM32_TAMP_BASE   0x4601
  



Reviewed-by: Patrick Delaunay 

Thanks
Patrick



Re: [PATCH 0/2] arm: dts: Add Itap Delay Value For High Speed DDR

2024-01-19 Thread Nishanth Menon
On 07:20-20240110, Bryan Brattlof wrote:
> On January 10, 2024 thus sayeth Bhavya Kapoor:
> > 
> > On 08/01/24 7:35 pm, Bryan Brattlof wrote:
> > > Hi Bhavya!
> > > 
> > > On January  8, 2024 thus sayeth Bhavya Kapoor:
> > > > This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
> > > > J7200 SoC and for DDR50 speed mode for MMCSD in J721s2 SoC.
> > > > 
> > > > Bhavya Kapoor (2):
> > > >arm: dts: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode
> > > >arm: dts: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode
> > > > 
> > > >   arch/arm/dts/k3-j7200-main.dtsi  | 1 +
> > > >   arch/arm/dts/k3-j721s2-main.dtsi | 1 +
> > > Because of the periodic syncs with the kernel, modifying these dt files
> > > in U-Boot will cause confusion. (Which node is correct why did we have
> > > to do this in U-Boot and not in the Kernel... bla bla bla) If they
> > > absolutely need to go in now please override these nodes in the
> > > *-u-boot.dtsi files with a comment so we can keep track of these changes
> > > during the next sync with Linux.
> > > 
> > > ~Bryan
> > 
> > Hi Bryan, Fyi, This patch went in kernel as well.
> > 
> > Can be tracked below-
> > 
> > https://lore.kernel.org/all/170266085077.3490141.14935960940418963459.b4...@ti.com/
> > 
> > So , kernel and uboot dt files will remain in sync.
> > 
> 
> Sorry I may be missing something. Why do we need these properties in 
> U-Boot now? Why not wait 2 weeks for the v6.8-rc1 tag in Linux and sync 
> everything all at once?

I agree. NAK for the series. Please get this part of dts sync.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D


[PATCH] test/py: scsi: Add test for scsi commands

2024-01-19 Thread Love Kumar
Add a following test cases for scsi commands:
scsi_reset - To reset SCSI controller
scsi_info - To show available SCSI devices
scsi_scan - To (re-)scan SCSI bus
scsi_device - To show or set surrent device
scsi_part - To print partition table of selected SCSI device

Signed-off-by: Love Kumar 
---
 test/py/tests/test_scsi.py | 92 ++
 1 file changed, 92 insertions(+)
 create mode 100644 test/py/tests/test_scsi.py

diff --git a/test/py/tests/test_scsi.py b/test/py/tests/test_scsi.py
new file mode 100644
index ..be2e283e7d25
--- /dev/null
+++ b/test/py/tests/test_scsi.py
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+the SCSI device number, type and capacity. This test will be automatically
+skipped without this.
+
+For example:
+
+# Setup env__scsi_device_test to set the SCSI device number/slot, the type of
+device, and the device capacity in MB.
+env__scsi_device_test = {
+'dev_num': 0,
+'device_type': 'Hard Disk',
+'device_capacity': '476940.0 MB',
+}
+"""
+
+def scsi_setup(u_boot_console):
+f = u_boot_console.config.env.get('env__scsi_device_test', None)
+if not f:
+pytest.skip('No SCSI device to test')
+
+dev_num = f.get('dev_num', None)
+if not isinstance(dev_num, int):
+pytest.skip('No device number specified in env file to read')
+
+dev_type = f.get('device_type')
+if not dev_type:
+pytest.skip('No device type specified in env file to read')
+
+dev_size = f.get('device_capacity')
+if not dev_size:
+pytest.skip('No device capacity specified in env file to read')
+
+return dev_num, dev_type, dev_size
+
+@pytest.mark.buildconfigspec('cmd_scsi')
+def test_scsi_reset(u_boot_console):
+dev_num, dev_type, dev_size = scsi_setup(u_boot_console)
+output = u_boot_console.run_command('scsi reset')
+assert f'Device {dev_num}:' in output
+assert f'Type: {dev_type}' in output
+assert f'Capacity: {dev_size}' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+@pytest.mark.buildconfigspec('cmd_scsi')
+def test_scsi_info(u_boot_console):
+dev_num, dev_type, dev_size = scsi_setup(u_boot_console)
+output = u_boot_console.run_command('scsi info')
+assert f'Device {dev_num}:' in output
+assert f'Type: {dev_type}' in output
+assert f'Capacity: {dev_size}' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+@pytest.mark.buildconfigspec('cmd_scsi')
+def test_scsi_scan(u_boot_console):
+dev_num, dev_type, dev_size = scsi_setup(u_boot_console)
+output = u_boot_console.run_command('scsi scan')
+assert f'Device {dev_num}:' in output
+assert f'Type: {dev_type}' in output
+assert f'Capacity: {dev_size}' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+@pytest.mark.buildconfigspec('cmd_scsi')
+def test_scsi_dev(u_boot_console):
+dev_num, dev_type, dev_size = scsi_setup(u_boot_console)
+output = u_boot_console.run_command('scsi device')
+assert 'no scsi devices available' not in output
+assert f'device {dev_num}:' in output
+assert f'Type: {dev_type}' in output
+assert f'Capacity: {dev_size}' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+output = u_boot_console.run_command('scsi device %d' % dev_num)
+assert 'is now current device' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+@pytest.mark.buildconfigspec('cmd_scsi')
+def test_scsi_part(u_boot_console):
+test_scsi_dev(u_boot_console)
+output = u_boot_console.run_command('scsi part')
+assert 'Partition Map for SCSI device' in output
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
-- 
2.25.1



[PATCH] test/py: spi: Add tests for SPI flash device

2024-01-19 Thread Love Kumar
Add test cases for sf commands to verify various SPI flash operations
such as erase, write and read. It also adds qspi lock unlock cases.
This test relies on boardenv_* configurations to run it for different
SPI flash family such as single SPI, QSPI, and OSPI.

Signed-off-by: Love Kumar 
---
 test/py/tests/test_spi.py | 626 ++
 1 file changed, 626 insertions(+)
 create mode 100644 test/py/tests/test_spi.py

diff --git a/test/py/tests/test_spi.py b/test/py/tests/test_spi.py
new file mode 100644
index ..a0b5c075b6ce
--- /dev/null
+++ b/test/py/tests/test_spi.py
@@ -0,0 +1,626 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import random
+import re
+import u_boot_utils
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+spi minimum and maximum frequnecies at which the flash part can operate on and
+these tests run at 5 different spi frequnecy randomised values in the range.
+It also defines the SPI bus number containing the SPI-flash chip, SPI
+chip-select, SPI mode, SPI flash part name and timeout parameters. If minimum
+and maximum frequency is not defined, it will run on freq 0 by default.
+
+Without the boardenv_* configuration, this test will be automatically skipped.
+
+It also relies on configuration values for supported flashes for qspi lock and
+unlock cases. It will run qspi lock-unlock cases only for the supported flash
+parts.
+
+Example:
+env__spi_device_test = {
+'bus': 0,
+'chip_select': 0,
+'min_freq': 1000,
+'max_freq': 1,
+'mode': 0,
+'part_name': 'n25q00a',
+'timeout': 10,
+}
+
+env__qspi_lock_unlock = {
+'supported_flash': 'mt25qu512a, n25q00a, n25q512ax3',
+}
+"""
+
+def setup_spi(u_boot_console):
+f = u_boot_console.config.env.get('env__spi_device_test', None)
+if not f:
+pytest.skip('No env file to read for SPI family device test')
+
+bus = f.get('bus', 0)
+cs = f.get('chip_select', 0)
+mode = f.get('mode', 0)
+part_name = f.get('part_name', None)
+timeout = f.get('timeout', None)
+
+if not part_name:
+pytest.skip('No env file to read SPI family flash part name')
+
+return bus, cs, mode, part_name, timeout
+
+# Find out minimum and maximum frequnecies that SPI device can operate
+def spi_find_freq_range(u_boot_console):
+f = u_boot_console.config.env.get('env__spi_device_test', None)
+if not f:
+pytest.skip('No env file to read for SPI family device test')
+
+min_f = f.get('min_freq', None)
+max_f = f.get('max_freq', None)
+
+if not min_f:
+min_f = 0
+if not max_f:
+max_f = 0
+if max_f < min_f:
+max_f = min_f
+
+if min_f == 0 and max_f == 0:
+iterations = 1
+else:
+iterations = 5
+
+return min_f, max_f, iterations
+
+# Find out SPI family flash memory parameters
+def spi_pre_commands(u_boot_console, freq):
+bus, cs, mode, part_name, timeout = setup_spi(u_boot_console)
+
+output = u_boot_console.run_command(f'sf probe {bus}:{cs} {freq} {mode}')
+if not 'SF: Detected' in output:
+pytest.skip('No SPI device available')
+
+if not part_name in output:
+pytest.fail('SPI flash part name not recognized')
+
+m = re.search('page size (.+?) Bytes', output)
+if m:
+try:
+page_size = int(m.group(1))
+except ValueError:
+pytest.fail('SPI page size not recognized')
+
+m = re.search('erase size (.+?) KiB', output)
+if m:
+try:
+erase_size = int(m.group(1))
+except ValueError:
+pytest.fail('SPI erase size not recognized')
+
+erase_size *= 1024
+
+m = re.search('total (.+?) MiB', output)
+if m:
+try:
+global total_size
+total_size = int(m.group(1))
+except ValueError:
+pytest.fail('SPI total size not recognized')
+
+total_size *= 1024 * 1024
+
+m = re.search('Detected (.+?) with', output)
+if m:
+try:
+flash_part = m.group(1)
+assert flash_part == part_name
+except:
+pytest.fail('SPI flash part not recognized')
+
+return page_size, erase_size, total_size, flash_part, timeout
+
+# Read the whole SPI flash twice, random_size till full flash size, random
+# till page size
+def spi_read_twice(u_boot_console, page_size, total_size, timeout):
+expected_read = 'Read: OK'
+
+for size in random.randint(4, page_size), random.randint(4, total_size), 
total_size:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+size = size & ~3
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command(
+'sf read %x 0 %x' % (addr + total_size, size)
+)
+assert expected_read in output
+output = 

[PATCH] test/py: nand: Add tests for NAND flash device

2024-01-19 Thread Love Kumar
Add tests for nand commands to test various NAND flash operations such
as erase, write and read.

Signed-off-by: Love Kumar 
---
 test/py/tests/test_nand.py | 201 +
 1 file changed, 201 insertions(+)
 create mode 100644 test/py/tests/test_nand.py

diff --git a/test/py/tests/test_nand.py b/test/py/tests/test_nand.py
new file mode 100644
index ..f5fd5d065cfe
--- /dev/null
+++ b/test/py/tests/test_nand.py
@@ -0,0 +1,201 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import random
+import re
+import u_boot_utils
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+the nand device total size and timeout available for testing. Without this, the
+test will be automatically skipped. This test will be also skipped if the NAND
+flash device is not detected.
+
+For example:
+
+# Setup env__nand_device_test to set the NAND flash total size and timeout.
+env__nand_device_test = {
+   'size': '8192 MB',
+   'timeout': 10,
+}
+"""
+
+# Find out nand memory parameters
+def nand_pre_commands(u_boot_console):
+f = u_boot_console.config.env.get('env__nand_device_test', None)
+if not f:
+pytest.skip('No env file to read for NAND device test')
+
+total_size = f.get('size', None)
+timeout = f.get('timeout')
+
+if not total_size:
+pytest.skip('NAND device size not recognized')
+
+output = u_boot_console.run_command('nand info')
+if not 'Device 0: nand0' in output:
+pytest.skip('No NAND device available')
+
+m = re.search('Page size (.+?) b', output)
+if m:
+try:
+page_size = int(m.group(1))
+except ValueError:
+pytest.fail('NAND page size not recognized')
+
+m = re.search('sector size (.+?) KiB', output)
+if m:
+try:
+erase_size = int(m.group(1))
+sector_size = erase_size
+except ValueError:
+pytest.fail('NAND erase size not recognized')
+
+erase_size *= 1024
+
+output = u_boot_console.run_command('nand bad')
+if not 'bad blocks:' in output:
+pytest.skip('No NAND device available')
+
+count = 0
+m = re.search('bad blocks:([\n\s\s\d\w]*)', output)
+if m:
+print(m.group(1))
+var = m.group(1).split()
+count = len(var)
+print('bad blocks count= ' + str(count))
+
+m = re.search('(.+?) MB', total_size)
+if m:
+try:
+total_size = int(m.group(1))
+total_size *= 1024 * 1024
+print('Total size is: ' + str(total_size) + ' B')
+total_size -= count * sector_size * 1024
+print('New Total size is: ' + str(total_size) + ' B')
+except ValueError:
+pytest.fail('NAND size not recognized')
+
+return page_size, erase_size, total_size, sector_size, timeout
+
+@pytest.mark.buildconfigspec('cmd_nand')
+@pytest.mark.buildconfigspec('cmd_bdi')
+@pytest.mark.buildconfigspec('cmd_memory')
+def test_nand_read_twice(u_boot_console):
+"""This test reads the whole NAND flash twice, random_size till full flash
+size, random till page size.
+"""
+
+page_size, erase_size, total_size, sector_size, timeout = 
nand_pre_commands(
+u_boot_console)
+expected_read = 'read: OK'
+
+for size in random.randint(4, page_size), random.randint(4, total_size), 
total_size:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+output = u_boot_console.run_command(
+'nand read %x 0 %x' % (addr + total_size, size)
+)
+assert expected_read in output
+
+output = u_boot_console.run_command('crc32 %x %x' % (addr + 
total_size, size))
+m = re.search('==> (.+?)', output)
+if not m:
+pytest.fail('CRC32 failed')
+expected_crc32 = m.group(1)
+
+output = u_boot_console.run_command(
+'nand read %x 0 %x' % (addr + total_size + 10, size)
+)
+assert expected_read in output
+
+output = u_boot_console.run_command(
+'crc32 %x %x' % (addr + total_size + 10, size)
+)
+assert expected_crc32 in output
+
+@pytest.mark.buildconfigspec('cmd_nand')
+@pytest.mark.buildconfigspec('cmd_bdi')
+@pytest.mark.buildconfigspec('cmd_memory')
+def test_nand_write_twice(u_boot_console):
+"""This test does the random writes till page size, size and full size"""
+
+page_size, erase_size, total_size, sector_size, timeout = 
nand_pre_commands(
+u_boot_console)
+expected_write = 'written: OK'
+expected_read = 'read: OK'
+expected_erase = '100% complete.'
+old_size = 0
+
+for size in (
+random.randint(4, page_size),
+random.randint(page_size, total_size),
+total_size,
+):
+offset = page_size
+addr = u_boot_utils.find_ram_base(u_boot_console)
+size = size - old_size
+

[PATCH] test/py: usb: Add tests for USB device

2024-01-19 Thread Love Kumar
Add the test cases for usb commands to test its various functionality
such as start, stop, reset, info, tree, storage, dev, part, ls, load,
and save. It also adds different file systems cases such as fat32, ext2
and ext4.

Signed-off-by: Love Kumar 
---
 test/py/tests/test_usb.py | 626 ++
 1 file changed, 626 insertions(+)
 create mode 100644 test/py/tests/test_usb.py

diff --git a/test/py/tests/test_usb.py b/test/py/tests/test_usb.py
new file mode 100644
index ..fb3d20f0826b
--- /dev/null
+++ b/test/py/tests/test_usb.py
@@ -0,0 +1,626 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import random
+import re
+import u_boot_utils
+
+"""
+Note: This test doesn't rely on boardenv_* configuration values but it can
+change the test behavior. To test USB file system cases (fat32, ext2, ext4),
+USB device should be formatted and valid partitions should be created for
+different file system, otherwise it may leads to failure. This test will be
+skipped if the USB device is not detected.
+
+For example:
+
+# Setup env__usb_device_test_skip to not skipping the test. By default, its
+# value is set to True. Set it to False to run all tests for USB device.
+env__usb_device_test_skip = False
+"""
+
+def setup_usb(u_boot_console):
+if u_boot_console.config.env.get('env__usb_device_test_skip', True):
+pytest.skip('USB device test is not enabled')
+
+@pytest.mark.buildconfigspec('cmd_usb')
+def test_usb_start(u_boot_console):
+setup_usb(u_boot_console)
+output = u_boot_console.run_command('usb start')
+
+# if output is empty, usb start may already run as part of preboot command
+# re-start the usb, in that case
+if not output:
+u_boot_console.run_command('usb stop')
+output = u_boot_console.run_command('usb start')
+
+if 'No USB device found' in output:
+pytest.skip('No USB controller available')
+
+if 'Card did not respond to voltage select' in output:
+pytest.skip('No USB device present')
+
+controllers = 0
+storage_device = 0
+obj = re.search(r'\d USB Device\(s\) found', output)
+controllers = int(obj.group()[0])
+
+if not controllers:
+pytest.skip('No USB device present')
+
+obj = re.search(r'\d Storage Device\(s\) found', output)
+storage_device = int(obj.group()[0])
+
+if not storage_device:
+pytest.skip('No USB storage device present')
+
+assert 'USB init failed' not in output
+assert 'starting USB...' in output
+
+if 'Starting the controller' in output:
+assert 'USB XHCI' in output
+
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+return controllers, storage_device
+
+@pytest.mark.buildconfigspec('cmd_usb')
+def test_usb_stop(u_boot_console):
+setup_usb(u_boot_console)
+output = u_boot_console.run_command('usb stop')
+assert 'stopping USB..' in output
+
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+output = u_boot_console.run_command('usb dev')
+assert "USB is stopped. Please issue 'usb start' first." in output
+
+@pytest.mark.buildconfigspec('cmd_usb')
+def test_usb_reset(u_boot_console):
+setup_usb(u_boot_console)
+output = u_boot_console.run_command('usb reset')
+
+if 'No USB device found' in output:
+pytest.skip('No USB controller available')
+
+if 'Card did not respond to voltage select' in output:
+pytest.skip('No USB device present')
+
+obj = re.search(r'\d USB Device\(s\) found', output)
+usb_dev_num = int(obj.group()[0])
+
+if not usb_dev_num:
+pytest.skip('No USB device present')
+
+obj = re.search(r'\d Storage Device\(s\) found', output)
+usb_stor_num = int(obj.group()[0])
+
+if not usb_stor_num:
+pytest.skip('No USB storage device present')
+
+assert 'BUG' not in output
+assert 'USB init failed' not in output
+assert 'resetting USB...' in output
+
+if 'Starting the controller' in output:
+assert 'USB XHCI' in output
+
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+@pytest.mark.buildconfigspec('cmd_usb')
+def test_usb_info(u_boot_console):
+controllers, storage_device = test_usb_start(u_boot_console)
+output = u_boot_console.run_command('usb info')
+
+num_controller = len(re.findall(': Hub,', output))
+num_mass_storage = len(re.findall(': Mass Storage,', output))
+
+assert num_controller == controllers - 1
+assert num_mass_storage == storage_device
+
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+for i in range(0, storage_device + controllers - 1):
+output = u_boot_console.run_command('usb info %d' % i)
+num_controller = len(re.findall(': Hub,', output))
+num_mass_storage = len(re.findall(': Mass Storage,', output))
+assert 

[PATCH] test/py: mmc: Add tests for MMC device

2024-01-19 Thread Love Kumar
Add the test cases for mmc commands to test its various functionality
such as mmc list, dev, info, rescan, part, ls, load, and save. It also
adds different file systems cases such as fat32, ext2 and ext4.

Signed-off-by: Love Kumar 
---
 test/py/tests/test_mmc.py | 671 ++
 1 file changed, 671 insertions(+)
 create mode 100644 test/py/tests/test_mmc.py

diff --git a/test/py/tests/test_mmc.py b/test/py/tests/test_mmc.py
new file mode 100644
index ..a96c4e8fd890
--- /dev/null
+++ b/test/py/tests/test_mmc.py
@@ -0,0 +1,671 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import random
+import re
+import u_boot_utils
+
+"""
+Note: This test doesn't rely on boardenv_* configuration values but it can
+change the test behavior. To test MMC file system cases (fat32, ext2, ext4),
+MMC device should be formatted and valid partitions should be created for
+different file system, otherwise it may leads to failure. This test will be
+skipped if the MMC device is not detected.
+
+For example:
+
+# Setup env__mmc_device_test_skip to not skipping the test. By default, its
+# value is set to True. Set it to False to run all tests for MMC device.
+env__mmc_device_test_skip = False
+"""
+
+mmc_set_up = False
+controllers = 0
+devices = {}
+
+def setup_mmc(u_boot_console):
+if u_boot_console.config.env.get('env__mmc_device_test_skip', True):
+pytest.skip('MMC device test is not enabled')
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmc_list(u_boot_console):
+setup_mmc(u_boot_console)
+output = u_boot_console.run_command('mmc list')
+if 'No MMC device available' in output:
+pytest.skip('No SD/MMC/eMMC controller available')
+
+if 'Card did not respond to voltage select' in output:
+pytest.skip('No SD/MMC card present')
+
+array = output.split()
+global devices
+global controllers
+controllers = int(len(array) / 2)
+for x in range(0, controllers):
+y = x * 2
+devices[x] = {}
+devices[x]['name'] = array[y]
+
+global mmc_set_up
+mmc_set_up = True
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmc_dev(u_boot_console):
+if not mmc_set_up:
+pytest.skip('No SD/MMC/eMMC controller available')
+
+fail = 0
+for x in range(0, controllers):
+devices[x]['detected'] = 'yes'
+output = u_boot_console.run_command('mmc dev %d' % x)
+
+# Some sort of switch here
+if 'Card did not respond to voltage select' in output:
+fail = 1
+devices[x]['detected'] = 'no'
+
+if 'no mmc device at slot' in output:
+devices[x]['detected'] = 'no'
+
+if 'MMC: no card present' in output:
+devices[x]['detected'] = 'no'
+
+if fail:
+pytest.fail('Card not present')
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmcinfo(u_boot_console):
+if not mmc_set_up:
+pytest.skip('No SD/MMC/eMMC controller available')
+
+for x in range(0, controllers):
+if devices[x]['detected'] == 'yes':
+u_boot_console.run_command('mmc dev %d' % x)
+output = u_boot_console.run_command('mmcinfo')
+if 'busy timeout' in output:
+pytest.skip('No SD/MMC/eMMC device present')
+
+obj = re.search(r'Capacity: (\d+|\d+[\.]?\d)', output)
+try:
+capacity = float(obj.groups()[0])
+print(capacity)
+devices[x]['capacity'] = capacity
+print('Capacity of dev %d is: %g GiB' % (x, capacity))
+except ValueError:
+pytest.fail('MMC capacity not recognized')
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmc_info(u_boot_console):
+if not mmc_set_up:
+pytest.skip('No SD/MMC/eMMC controller available')
+
+for x in range(0, controllers):
+if devices[x]['detected'] == 'yes':
+u_boot_console.run_command('mmc dev %d' % x)
+
+output = u_boot_console.run_command('mmc info')
+
+obj = re.search(r'Capacity: (\d+|\d+[\.]?\d)', output)
+try:
+capacity = float(obj.groups()[0])
+print(capacity)
+if devices[x]['capacity'] != capacity:
+pytest.fail("MMC capacity doesn't match mmcinfo")
+
+except ValueError:
+pytest.fail('MMC capacity not recognized')
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmc_rescan(u_boot_console):
+if not mmc_set_up:
+pytest.skip('No SD/MMC/eMMC controller available')
+
+if not devices:
+pytest.skip('No devices detected')
+
+for x in range(0, controllers):
+if devices[x]['detected'] == 'yes':
+u_boot_console.run_command('mmc dev %d' % x)
+output = u_boot_console.run_command('mmc rescan')
+if output:
+

Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Ivan T. Ivanov



> On 19 Jan 2024, at 16:08, Jens Maus  wrote:
> 
> 
>> Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov :
>> 
>> On 01-19 14:54, Jens Maus wrote:
>>> 
 Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov :
 
 Same here, expect that they are more memory banks, of course.
 It is really strange that you don't seen even single message
 from the U-Boot..
>>> 
>>> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you 
>>> see any debug output on the serial debug probe connection to the rpi5?
>> 
>> Yes, there is even small submarine on the top right side of the screen
>> while U-Boot is running.
> 
> On the HDMI port, right? But what about the serial UART output? 

Yes, I can see serial output from U-Boot. I am using one of these
simple USB<->UART cables. You can see serial output when you boot
with RPiOS, when you use "Raspberry Pi Debug Probe”, right?

Ivan

Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Jens Maus


> Am 19.01.2024 um 15:06 schrieb Ivan T. Ivanov :
> 
> On 01-19 14:54, Jens Maus wrote:
>> 
>>> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov :
>>> 
>>> Same here, expect that they are more memory banks, of course.
>>> It is really strange that you don't seen even single message
>>> from the U-Boot..
>> 
>> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you 
>> see any debug output on the serial debug probe connection to the rpi5?
> 
> Yes, there is even small submarine on the top right side of the screen
> while U-Boot is running.

On the HDMI port, right? But what about the serial UART output? Is there 
anything U-Boot outputs right after the rpi boot loader is done? Here not. And 
as said, the same u-boot.bin boots up perfectly with a rpi4 and I can see the 
U-Boot submarine logo on the HDMI.

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/



Re: [PATCH] ARM: stm32: Set stdio to serial on DH STM32MP15xx DHSOM

2024-01-19 Thread Patrice CHOTARD



On 1/16/24 08:19, Patrice CHOTARD wrote:
> Hi Marek
> 
> On 1/13/24 18:57, Marek Vasut wrote:
>> In case CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV are enabled, the console
>> stdin, stdout, stderr must be defined in environment. Define the default
>> settings to fix the following warning on boot:
>>
>> "
>> In:No input devices available!
>> Out:   No output devices available!
>> Err:   No error devices available!
>> "
>>
>> Sort the default environment as well.
>>
>> Signed-off-by: Marek Vasut 
>> ---
>> Cc: Patrice Chotard 
>> Cc: Patrick Delaunay 
>> Cc: u-b...@dh-electronics.com
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
>>  include/configs/stm32mp15_dh_dhsom.h | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/configs/stm32mp15_dh_dhsom.h 
>> b/include/configs/stm32mp15_dh_dhsom.h
>> index 8ff882264f4..de39b19219d 100644
>> --- a/include/configs/stm32mp15_dh_dhsom.h
>> +++ b/include/configs/stm32mp15_dh_dhsom.h
>> @@ -12,14 +12,13 @@
>>  #define PHY_ANEG_TIMEOUT2
>>  
>>  #ifdef CONFIG_SPL_BUILD
>> -#define CFG_EXTRA_ENV_SETTINGS  \
>> +#define CFG_EXTRA_ENV_SETTINGS  
>> \
>>  "dfu_alt_info_ram=u-boot.itb ram "  \
>>  __stringify(CONFIG_SPL_LOAD_FIT_ADDRESS)\
>>  " 0x80\0"
>>  #endif
>>  
>> -#define STM32MP_BOARD_EXTRA_ENV \
>> -"usb_pgood_delay=1000\0" \
>> +#define STM32MP_BOARD_EXTRA_ENV 
>> \
>>  "dh_update_sd_to_emmc=" /* Install U-Boot from SD to eMMC */\
>>  "setexpr loadaddr1 ${loadaddr} + 0x100 && " \
>>  "load mmc 0:4 ${loadaddr1} boot/u-boot-spl.stm32 && "   \
>> @@ -49,7 +48,11 @@
>>  "sf update ${loadaddr1} 0x4 ${filesize1} && "   \
>>  "sf update ${loadaddr} 0x8 ${filesize} && " \
>>  "env set filesize1 && env set loadaddr1\0"  \
>> -"update_sf=run dh_update_sd_to_sf\0"
>> +"stdin=serial\0"\
>> +"stdout=serial\0"   \
>> +"stderr=serial\0"   \
>> +"update_sf=run dh_update_sd_to_sf\0"\
>> +"usb_pgood_delay=1000\0"
>>  
>>  
>>  #include 
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice

Applied to u-boot-stm32/master

Thanks
Patrice


Re: Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Ivan T. Ivanov
Hi,

On 01-19 14:54, Jens Maus wrote:
> 
> > Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov :
> > 
> > Same here, expect that they are more memory banks, of course.
> > It is really strange that you don't seen even single message
> > from the U-Boot..
> 
> Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you 
> see any debug output on the serial debug probe connection to the rpi5?

Yes, there is even small submarine on the top right side of the screen
while U-Boot is running.

> 
> Perhaps it is really dependent on the eeprom version? Can you perhaps try to 
> bump your eeprom version to the latest version to see if this might be the 
> culprit?
> 

Yes, will do this.

Regards,
Ivan



Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Jens Maus


> Am 19.01.2024 um 14:46 schrieb Ivan T. Ivanov :
> 
> Same here, expect that they are more memory banks, of course.
> It is really strange that you don't seen even single message
> from the U-Boot..

Indeed. Not a single line, nor any U-Boot logo or anything on HDMI. Do you see 
any debug output on the serial debug probe connection to the rpi5?

Perhaps it is really dependent on the eeprom version? Can you perhaps try to 
bump your eeprom version to the latest version to see if this might be the 
culprit?

regards,
jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/



Re: [PATCH v2 06/32] serial: msm: add debug UART

2024-01-19 Thread Caleb Connolly



On 18/01/2024 21:54, Ramon Fried wrote:
> On Tue, Dec 19, 2023 at 6:04 PM Caleb Connolly
>  wrote:
>>
>> Introduce support for early debugging.
>>
>> Signed-off-by: Caleb Connolly 
>> ---
>>  drivers/serial/Kconfig  |  8 
>>  drivers/serial/serial_msm.c | 32 
>>  2 files changed, 40 insertions(+)
>>
>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
>> index 81fdac047824..20713812c839 100644
>> --- a/drivers/serial/Kconfig
>> +++ b/drivers/serial/Kconfig
>> @@ -304,6 +304,14 @@ config DEBUG_UART_S5P
>>   will need to provide parameters to make this work. The driver will
>>   be available until the real driver-model serial is running.
>>
>> +config DEBUG_UART_MSM
>> +   bool "Qualcomm QUP UART debug"
> What is QUP ?

It's "Qualcomm Universal Peripheral".
>> +   depends on ARCH_SNAPDRAGON
>> +   help
>> + Select this to enable a debug UART using the serial_msm driver. You
>> + will need to provide parameters to make this work. The driver will
>> + be available until the real driver-model serial is running.
>> +
>>  config DEBUG_UART_MSM_GENI
>> bool "Qualcomm snapdragon"
>> depends on ARCH_SNAPDRAGON
>> diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
>> index a22623c316ed..19a5a3a788f7 100644
>> --- a/drivers/serial/serial_msm.c
>> +++ b/drivers/serial/serial_msm.c
>> @@ -253,3 +253,35 @@ U_BOOT_DRIVER(serial_msm) = {
>> .probe = msm_serial_probe,
>> .ops= _serial_ops,
>>  };
>> +
>> +#ifdef CONFIG_DEBUG_UART_MSM
>> +
>> +static struct msm_serial_data init_serial_data = {
>> +   .base = CONFIG_VAL(DEBUG_UART_BASE),
>> +   .clk_bit_rate = UART_DM_CLK_RX_TX_BIT_RATE,
>> +};
>> +
>> +#include 
>> +
>> +static inline void _debug_uart_init(void)
>> +{
>> +   uart_dm_init(_serial_data);
>> +}
>> +
>> +static inline void _debug_uart_putc(int ch)
>> +{
>> +   struct msm_serial_data *priv = _serial_data;
>> +
>> +   while (!(readl(priv->base + UARTDM_SR) & UARTDM_SR_TX_EMPTY) &&
>> +  !(readl(priv->base + UARTDM_ISR) & UARTDM_ISR_TX_READY))
>> +   ;
>> +
>> +   writel(UARTDM_CR_CMD_RESET_TX_READY, priv->base + UARTDM_CR);
>> +
>> +   writel(1, priv->base + UARTDM_NCF_TX);
>> +   writel(ch, priv->base + UARTDM_TF);
>> +}
>> +
>> +DEBUG_UART_FUNCS
>> +
>> +#endif
>>
>> --
>> 2.42.1
>>

-- 
// Caleb (they/them)


Re: Re: [PATCH v4 0/6] rpi5: initial support

2024-01-19 Thread Ivan T. Ivanov
+ u-boot@lists.denx.de

I am not sure how I drop the list in my last email, sorry.

On 01-19 12:56, Jens Maus wrote:
> Hi Ivan,
> 
> > Am 19.01.2024 um 12:22 schrieb Ivan T. Ivanov :
> > 
> > On 01-19 11:49, Jens Maus wrote:
> >>> Am 19.01.2024 um 10:20 schrieb Stefan Wahren :
> >>> 
> >>> Another idea could be to dump the runtime DT of both variants via sysfs
> >>> (using official RPi OS) and compare them with each other. In the past
> >>> there was a lot DT firmware hackery for the Raspberry Pi 4.
> >> 
> >> Good idea indeed. I just did that and executed "dtc -I fs 
> >> /sys/firmware/devicetree/base“ in a quick RaspberryPiOS installation.
> >> 
> >> See [1] for the corresponding output. Hopefully Ivan can do the same so 
> >> that we can see if there are any differences that might
> >> explain why his u-boot patches are working for him while they does not for 
> >> me.
> >> 
> >> Best Regards,
> >> Jens
> >> 
> >> [1] https://gist.github.com/jens-maus/497e03cf1305ffe8a07e3196c27d6ebd
> > 
> > Thanks! Unfortunately at least first 2 memory banks looks the same as in 
> > 4GB version:
> > 
> > memory@0 {
> >device_type = "memory";
> >reg = <0x00 0x00 0x3f80 0x00 0x4000 0xc000>;
> > };
> > 
> > Jens, could you please, disconnect HDMI cable and capture devicetree
> > file again.
> 
> Sure. Here the diff against the other device tree at gist:
> 
> — cut here —
> --- device-tree   2024-01-19 11:33:41.831797039 +0100
> +++ device-tree2  2024-01-19 12:53:11.333845039 +0100
> @@ -2,7 +2,7 @@
>  
>  / {
>   #address-cells = <0x02>;
> - memreserve = <0x3f80 0x80>;
> + memreserve = <0x3fc0 0x40>;
>   model = "Raspberry Pi 5 Model B Rev 1.0";
>   serial-number = "6b206ca09127ae99";
>   #size-cells = <0x01>;
> @@ -41,7 +41,7 @@
>  
>   memory@0 {
>   device_type = "memory";
> - reg = <0x00 0x00 0x3f80 0x00 0x4000 0xc000 0x01 
> 0x00 0x8000 0x01 0x8000 0x8000>;
> + reg = <0x00 0x00 0x3fc0 0x00 0x4000 0xc000 0x01 
> 0x00 0x8000 0x01 0x8000 0x8000>;
>   };
>  

Same here, expect that they are more memory banks, of course.
It is really strange that you don't seen even single message
from the U-Boot..

Hm... Ivan



[PATCH RFC 2/2] clk: add clock framework for HiSilicon SoCs

2024-01-19 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

Hi3798 Series SoCs have a CRG (Clock Reset Generator) module which
manages all clocks and resets of the SoC.

The first supported chip is Hi3798MV200.  The unused clocks are not
registered to save space and time. Only necessary clocks are
implemented right now.

Signed-off-by: Yang Xiwen 
---
 drivers/clk/Kconfig |   7 ++
 drivers/clk/Makefile|   1 +
 drivers/clk/hisilicon/Kconfig   |  14 +++
 drivers/clk/hisilicon/Makefile  |   8 ++
 drivers/clk/hisilicon/clk-hi3798mv200.c | 213 
 drivers/clk/hisilicon/clk.c | 102 +++
 drivers/clk/hisilicon/clk.h |  55 +
 include/dt-bindings/clock/histb-clock.h |   4 +
 8 files changed, 404 insertions(+)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 017dd260a5..4c5ac46b26 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -127,6 +127,12 @@ config CLK_ICS8N3QV01
  Crystal Oscillator). The output frequency can be programmed via an
  I2C interface.
 
+config CLK_HISI
+   bool "Enable Hisilicon Clock Framework"
+   depends on CLK && CLK_CCF
+   help
+ Support for Hisilicon Clock Framework.
+
 config CLK_INTEL
bool "Enable clock driver for Intel x86"
depends on CLK && X86
@@ -249,6 +255,7 @@ config CLK_ZYNQMP
 source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
+source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/imx/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/microchip/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 638ad04bae..90e7e1b5f4 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
+obj-$(CONFIG_CLK_HISI) += hisilicon/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_K210) += clk_k210.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
new file mode 100644
index 00..caa51b7831
--- /dev/null
+++ b/drivers/clk/hisilicon/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if CLK_HISI
+menu "HiSilicon CRG Driver"
+
+config COMMON_CLK_HI3798MV200
+   tristate "Hi3798MV200 CRG Driver"
+   select RESET_HISILICON
+   depends on ARCH_HISTB
+   help
+ Build the CRG driver for Hi3798MV200.
+
+endmenu
+endif
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
new file mode 100644
index 00..85a0ffb4a1
--- /dev/null
+++ b/drivers/clk/hisilicon/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Hisilicon Clock specific Makefile
+#
+
+obj-y  += clk.o
+
+obj-$(CONFIG_COMMON_CLK_HI3798MV200)   += clk-hi3798mv200.o
diff --git a/drivers/clk/hisilicon/clk-hi3798mv200.c 
b/drivers/clk/hisilicon/clk-hi3798mv200.c
new file mode 100644
index 00..01bb20d940
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3798mv200.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hi3798MV200 Clock and Reset Generator Driver.
+ * Adapted from clk-hi3798cv200.c.
+ *
+ * Copyright (c) 2024 Yang Xiwen 
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+/* hi3798MV200 core CRG */
+#define HI3798MV200_INNER_CLK_OFFSET   64
+#define HI3798MV200_FIXED_12M  65
+#define HI3798MV200_FIXED_24M  66
+#define HI3798MV200_FIXED_25M  67
+#define HI3798MV200_FIXED_27M  68
+#define HI3798MV200_FIXED_48M  69
+#define HI3798MV200_FIXED_50M  70
+#define HI3798MV200_FIXED_54M  71
+#define HI3798MV200_FIXED_60M  72
+#define HI3798MV200_FIXED_75M  73
+#define HI3798MV200_FIXED_100M 74
+#define HI3798MV200_FIXED_150M 75
+#define HI3798MV200_FIXED_166P5M   76
+#define HI3798MV200_FIXED_200M 77
+#define HI3798MV200_FIXED_250M 78
+#define HI3798MV200_FIXED_300M 79
+#define HI3798MV200_FIXED_400M 80
+#define HI3798MV200_MMC_MUX81
+#define HI3798MV200_COMBPHY1_MUX   82
+#define HI3798MV200_SDIO0_MUX  83
+#define HI3798MV200_COMBPHY0_MUX   84
+#define HI3798MV200_SDIO1_MUX  85
+#define HI3798MV200_ETH_MUX86
+
+static const struct hisi_fixed_rate_clock hi3798mv200_fixed_rate_clks[] = {
+   { HISTB_OSC_CLK, "clk_osc", 2400, },
+   { HISTB_APB_CLK, "clk_apb", 1, },
+   { HISTB_AHB_CLK, "clk_ahb", 2, },
+   { HI3798MV200_FIXED_12M, "12m", 

[PATCH RFC 0/2] clk: add HiSilicon CLK framework

2024-01-19 Thread Yang Xiwen via B4 Relay
The first supported chip is Hi3798MV200.

Signed-off-by: Yang Xiwen 
---
Yang Xiwen (2):
  clk: ccf: Export clk_register_mux_table() in linux/clk-provider.h
  clk: add clock framework for HiSilicon SoCs

 drivers/clk/Kconfig |   7 ++
 drivers/clk/Makefile|   1 +
 drivers/clk/hisilicon/Kconfig   |  14 +++
 drivers/clk/hisilicon/Makefile  |   8 ++
 drivers/clk/hisilicon/clk-hi3798mv200.c | 213 
 drivers/clk/hisilicon/clk.c | 102 +++
 drivers/clk/hisilicon/clk.h |  55 +
 include/dt-bindings/clock/histb-clock.h |   4 +
 include/linux/clk-provider.h|   6 +
 9 files changed, 410 insertions(+)
---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240119-b4-hisi-clk-88075b46c359

Best regards,
-- 
Yang Xiwen 



[PATCH RFC 1/2] clk: ccf: Export clk_register_mux_table() in linux/clk-provider.h

2024-01-19 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

This function is used by HiSilicon Clock Framework.

Signed-off-by: Yang Xiwen 
---
 include/linux/clk-provider.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index b8acacd49e..952439ad39 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -247,6 +247,12 @@ struct clk *clk_register_mux(struct device *dev, const 
char *name,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags);
 
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+   const char * const *parent_names, u8 num_parents,
+   unsigned long flags,
+   void __iomem *reg, u8 shift, u32 mask,
+   u8 clk_mux_flags, u32 *table);
+
 struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
ulong rate);
 

-- 
2.43.0



[PATCH RFC 2/2] clk: add clock framework for HiSilicon SoCs

2024-01-19 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

Hi3798 Series SoCs have a CRG (Clock Reset Generator) module which
manages all clocks and resets of the SoC.

The first supported chip is Hi3798MV200.  The unused clocks are not
registered to save space and time. Only necessary clocks are
implemented right now.

Signed-off-by: Yang Xiwen 
---
 drivers/clk/Kconfig |   7 ++
 drivers/clk/Makefile|   1 +
 drivers/clk/hisilicon/Kconfig   |  14 +++
 drivers/clk/hisilicon/Makefile  |   8 ++
 drivers/clk/hisilicon/clk-hi3798mv200.c | 213 
 drivers/clk/hisilicon/clk.c | 102 +++
 drivers/clk/hisilicon/clk.h |  55 +
 include/dt-bindings/clock/histb-clock.h |   4 +
 8 files changed, 404 insertions(+)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 017dd260a5..4c5ac46b26 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -127,6 +127,12 @@ config CLK_ICS8N3QV01
  Crystal Oscillator). The output frequency can be programmed via an
  I2C interface.
 
+config CLK_HISI
+   bool "Enable Hisilicon Clock Framework"
+   depends on CLK && CLK_CCF
+   help
+ Support for Hisilicon Clock Framework.
+
 config CLK_INTEL
bool "Enable clock driver for Intel x86"
depends on CLK && X86
@@ -249,6 +255,7 @@ config CLK_ZYNQMP
 source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
+source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/imx/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/microchip/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 638ad04bae..90e7e1b5f4 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
+obj-$(CONFIG_CLK_HISI) += hisilicon/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_K210) += clk_k210.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
new file mode 100644
index 00..caa51b7831
--- /dev/null
+++ b/drivers/clk/hisilicon/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if CLK_HISI
+menu "HiSilicon CRG Driver"
+
+config COMMON_CLK_HI3798MV200
+   tristate "Hi3798MV200 CRG Driver"
+   select RESET_HISILICON
+   depends on ARCH_HISTB
+   help
+ Build the CRG driver for Hi3798MV200.
+
+endmenu
+endif
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
new file mode 100644
index 00..85a0ffb4a1
--- /dev/null
+++ b/drivers/clk/hisilicon/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Hisilicon Clock specific Makefile
+#
+
+obj-y  += clk.o
+
+obj-$(CONFIG_COMMON_CLK_HI3798MV200)   += clk-hi3798mv200.o
diff --git a/drivers/clk/hisilicon/clk-hi3798mv200.c 
b/drivers/clk/hisilicon/clk-hi3798mv200.c
new file mode 100644
index 00..01bb20d940
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3798mv200.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hi3798MV200 Clock and Reset Generator Driver.
+ * Adapted from clk-hi3798cv200.c.
+ *
+ * Copyright (c) 2024 Yang Xiwen 
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+/* hi3798MV200 core CRG */
+#define HI3798MV200_INNER_CLK_OFFSET   64
+#define HI3798MV200_FIXED_12M  65
+#define HI3798MV200_FIXED_24M  66
+#define HI3798MV200_FIXED_25M  67
+#define HI3798MV200_FIXED_27M  68
+#define HI3798MV200_FIXED_48M  69
+#define HI3798MV200_FIXED_50M  70
+#define HI3798MV200_FIXED_54M  71
+#define HI3798MV200_FIXED_60M  72
+#define HI3798MV200_FIXED_75M  73
+#define HI3798MV200_FIXED_100M 74
+#define HI3798MV200_FIXED_150M 75
+#define HI3798MV200_FIXED_166P5M   76
+#define HI3798MV200_FIXED_200M 77
+#define HI3798MV200_FIXED_250M 78
+#define HI3798MV200_FIXED_300M 79
+#define HI3798MV200_FIXED_400M 80
+#define HI3798MV200_MMC_MUX81
+#define HI3798MV200_COMBPHY1_MUX   82
+#define HI3798MV200_SDIO0_MUX  83
+#define HI3798MV200_COMBPHY0_MUX   84
+#define HI3798MV200_SDIO1_MUX  85
+#define HI3798MV200_ETH_MUX86
+
+static const struct hisi_fixed_rate_clock hi3798mv200_fixed_rate_clks[] = {
+   { HISTB_OSC_CLK, "clk_osc", 2400, },
+   { HISTB_APB_CLK, "clk_apb", 1, },
+   { HISTB_AHB_CLK, "clk_ahb", 2, },
+   { HI3798MV200_FIXED_12M, "12m", 

[PATCH RFC 0/2] clk: add HiSilicon CLK framework

2024-01-19 Thread Yang Xiwen via B4 Relay
The first supported chip is Hi3798MV200.

Signed-off-by: Yang Xiwen 
---
Yang Xiwen (2):
  clk: ccf: Export clk_register_mux_table() in linux/clk-provider.h
  clk: add clock framework for HiSilicon SoCs

 drivers/clk/Kconfig |   7 ++
 drivers/clk/Makefile|   1 +
 drivers/clk/hisilicon/Kconfig   |  14 +++
 drivers/clk/hisilicon/Makefile  |   8 ++
 drivers/clk/hisilicon/clk-hi3798mv200.c | 213 
 drivers/clk/hisilicon/clk.c | 102 +++
 drivers/clk/hisilicon/clk.h |  55 +
 include/dt-bindings/clock/histb-clock.h |   4 +
 include/linux/clk-provider.h|   6 +
 9 files changed, 410 insertions(+)
---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240119-b4-hisi-clk-88075b46c359

Best regards,
-- 
Yang Xiwen 



[PATCH RFC 1/2] clk: ccf: Export clk_register_mux_table() in linux/clk-provider.h

2024-01-19 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

This function is used by HiSilicon Clock Framework.

Signed-off-by: Yang Xiwen 
---
 include/linux/clk-provider.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index b8acacd49e..952439ad39 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -247,6 +247,12 @@ struct clk *clk_register_mux(struct device *dev, const 
char *name,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags);
 
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+   const char * const *parent_names, u8 num_parents,
+   unsigned long flags,
+   void __iomem *reg, u8 shift, u32 mask,
+   u8 clk_mux_flags, u32 *table);
+
 struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
ulong rate);
 

-- 
2.43.0



  1   2   >