date:20230621


On 6/20/23 16:37, Jagan Teki wrote:

Hi,

Has anyone tried to use dwc2 and echi port together with USB disk?
look like this is not working with this combination on any Rockchip
SoC's

Here are the issues that I've reproduced in RK3328 where the disk
connected in EHCI port is detecting but DWC2 is not. Any clue?


I generally avoid using DWC2 as host. RPi 1/2/3 does use it as host, but 
I think there is a hub between.


Does the stick work if you plug a hub between the board and stick ?

Also, RPi zero (?) might have raw host port on it, without hub .

Re: [PULL] u-boot-usb/master

On Wed, Jun 21, 2023 at 04:21:18PM +0200, Marek Vasut wrote:

> The following changes since commit 50842b217fef505a0ec6662cc2acdc55d0bb23c5:
> 
>   Merge tag 'u-boot-at91-fixes-2023.07-a' of 
> https://source.denx.de/u-boot/custodians/u-boot-at91 (2023-06-19 09:18:40 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 9c9454ac2e4ffd9a8b30744329029f1676d2e7be:
> 
>   usb: dwc2: Fix the write to W1C fields in HPRT register (2023-06-21 
> 13:15:58 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-21 Thread Sam Edwards

On 6/21/23 04:55, Andre Przywara wrote:

On Tue, 20 Jun 2023 16:11:48 -0600
Sam Edwards wrote:

Hi Sam,

pleasure to write with you ;-)

Hi Andre,

Likewise!

Well, so this is actually the fallback implementation which should
somewhat work on most SoCs: set a flag, reset, and catch the flag in
the SPL. For modern SoCs with CPU hotplug support (the H616 is one one
of those, and it looks like the T113s is as well), there is actually a more
direct route:

Oh man, I would definitely prefer a direct route that doesn't require
the SPL coming up a second time, but...

We put some magic and the FEL entry address into some special memory
locations, then just reset. Now the *BootROM* will do the check already,
and branch to the provided entry point, which would be the FEL routine.
This doesn't rely on a prepared SPL to be loaded, so works without a
boot device with mainline U-Boot around.
Refer to section 3.4.2.3 and 3.4.2.4 of the T113-S3 user manual (v1.1).
According to this, the magic would be 0xfa50392f, the magic's address is
0x070005C0, and CPU0's entry point address would be in 0x070005C4. I had a
proof of concept implementation for the H616 using this method.

...I tried this and it seems that the 070005C* block hardware-resets to
zero before BROM runs. Is there a softer reset method you had in mind
that would avoid this?

The only
problem left would be that someone needs to clean the magic afterwards,
otherwise any follow-up reset would trigger FEL mode again.
That's at least pretty fixable though: instead of setting the entry
address to the FEL entry point, set it to a thunk placed in SRAM that
clears the flag before continuing onward to FEL.

The "fel-reset" command (which is easier to type than what I have, "run
fel_do_enter") would then call sunxi_fel_flag_set() and initiate a
reset, and the SPL's early init just has to do sunxi_fel_flag_test() ->
sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough.

Could you recommend to me a sufficiently different chip to test my
abstractions against? Something ARMv8 and *without* RTC?

I think all ARMv8 parts have an RTC, so your generic approach might work
there as well. The complication is that the SPL switches to AArch64 very
early, in hand-stitched AArch32 assembly, check out
arch/arm/include/asm/arch-sunxi/boot0.h.
The check would need to be coded like this, then.

I can then send
in a series adding FEL support for that. (Also, did that H3 patch
actually land? I didn't see anything but want to know if I should be
refactoring my approach to extend what that H3 patch does or not.)

https://patchwork.ozlabs.org/project/uboot/patch/c211aa414c59e7275fef82bf6f0035276d6e29f3.1656875482.git.msucha...@suse.de/

This approach seems close to mine, only my go_to_fel() enters by way of
return_to_fel() after first modifying fel_stash.lr, since the
return_to_fel() mechanism already takes care of restoring the core to a
BROM-friendly state.

One might abuse the board as a T113s dev
board, maybe ;-) Does it work without any of the modules populated?

Sure, if you're thinking about getting one. You just need an ATX-pinout
PSU to power the BMC (it runs off of the 5V standby rail).

... having a board. So far you are the one contributor with access to
the hardware, so: thanks for volunteering! ;-)

Andre, please, I know you're being tongue-in-cheek here, but I said
"no." We should have reached the agree-to-disagree point 2 emails ago:
you've made your (very compelling) case for why downstream would benefit
from the early expertise of the upstream DT reviewers, and how upstream
would benefit from having the DT for a second "real" T113-using board,
but at some point you need to trust that I understand that and that I
must therefore have very good reasons not to be distracting myself with
trying to (dual-)boot a mainline kernel yet. One thing at a time, y'know? :)

The U-Boot build system support some kind of build time DT "overlay"
feature: You put a file with the same name, but ending in
"-u-boot.dtsi" in the arch/arm/dts directory, and it will be included
into the DT which gets embedded into the U-Boot image. See
arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dts for an
example, and doc/develop/devicetree/control.rst for the proper
documentation.
So we upstream a minimal, non-controversial and non-contradicting base
.dts into the kernel tree, and can fix things up for the time being
using this method. This hack can then go away if either the mainline
kernel DT gets fixed and/or U-Boot learns the quad-SPI trick.

Oh, good to know! I'll try to remember that this option exists when the
time comes to use it.

Someone from the board vendor company actually actively adding upstream
support for their device early. There were some examples in the past
where employees participated in upstreaming, but I cannot remember
seeing this too often when it comes to the initial DT support.

I brought this email thread to the attention of the firmware

Re: [PATCH] test: dm: restore /firmware nodes after testing

On Thu, Jun 08, 2023 at 09:55:59AM +0900, AKASHI Takahiro wrote:

> dm_test_restore() is called after dm unit test is run.
> But this function does not scan any nodes under /firmware since
> it calls dm_scan_fdt().
> 
> This causes an issue. For instance, scmi_sandbox_agent device
> will disappear after running 'ut dm scmi_sandbox_agent'.
> 
> So call dm_extended_scan() instead. This change will be coherent
> with what dm_scan() and test_pre_run() does.
> 
> Signed-off-by: AKASHI Takahiro 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] stdio: Remove stdio_init()

On Tue, Jun 06, 2023 at 08:37:42PM +0900, Masahiro Yamada wrote:

> This function is not used by anyone.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] configs: am64x_evm_*_defconfig: Enable High Secure device support

On Sat, Jun 03, 2023 at 06:06:14PM +0530, Vignesh Raghavendra wrote:

> Enable CONFIG_TI_SECURE_DEVICE to support booting High Secure(HS)
> variants of AM64x SoC.
> 
> Signed-off-by: Vignesh Raghavendra 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] configs: synquacer: increase SYS_MALLOC_F_LEN

On Thu, Jun 01, 2023 at 06:13:51PM +0900, Masahisa Kojima wrote:

> DM_FLAG_PRE_RELOC flag is added into some drivers
> by recent commits such as
> 1bd790bc4b ("firmware: psci: enable DM_FLAG_PRE_RELOC").
> Current SYS_MALLOC_F_LEN of SynQuacer Developerbox platform
> is too small, Developerbox will not boot due to lack of
> heap memory.
> 
> This commit increases the size of heap memory.
> 
> Signed-off-by: Masahisa Kojima 
> Acked-by: Ilias Apalodimas 
> Acked-by: Jassi Brar 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] test: bdinfo: Add test for command bdinfo

On Wed, May 31, 2023 at 03:03:58AM +0200, Marek Vasut wrote:

> Add test for command bdinfo .
> 
> Signed-off-by: Marek Vasut 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] python: Update requirements.txt for security issues

On Tue, May 30, 2023 at 03:50:30PM -0400, Tom Rini wrote:

> Per GitHub Dependabot:
> - Use setuptools 65.5.1 to avoid some DoS issue
> - Use requests 2.31.0 to avoid leaking some proxy information
> 
> Signed-off-by: Tom Rini 
> Tested-by: Heinrich Schuchardt 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] drivers: spi: omap3_spi: Initialize mode for all channels

On Mon, May 29, 2023 at 03:42:28PM +0200, Julien Panis wrote:

> At first SPI transfers, multiple chip selects can be
> enabled simultaneously. This is due to chip select
> polarity, which is not properly initialized for all
> channels. This patch fixes the issue.
> 
> Signed-off-by: Julien Panis 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] psci: fix use of clobbered registers in asm

On Sat, May 27, 2023 at 06:09:42PM -0600, Sam Edwards wrote:

> The functions `psci_get_context_id` and `psci_get_target_pc`
> are written in C, so the C compiler may clobber registers r0-r3.
> Do not use these registers to save data across calls.
> 
> Signed-off-by: Sam Edwards 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mkimage: ecdsa: password for signing from environment

On Thu, May 25, 2023 at 10:18:05AM +0200, Stefano Babic wrote:

> Use a variable (MKIMAGE_SIGN_PASSWORD) like already done for RSA to
> allow the signing process to run in batch.
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Add CONFIG_GICV3 for ARCH_QEMU

On Mon, Jun 05, 2023 at 10:40:26AM +0900, Chan Kim wrote:

> I'm trying sending a patch for the first time.
> I found when running u-boot qemu_arm64_defconfig on qemu-6.2.0's arm64 virt
> machine, we need CONFIG_GICV3.
> And for the GICV3 related to be compiled, we need to add GICD_BASE,
> GICR_BASE defined by the qemu arm64 virt machine.
> 
> Signed-off-by : Chan Kim 

So I think some more investigation or explanation is needed here.  These
changes cause the way we currently run the qemu arm64 platform in CI to
no longer boot.  See
https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu_arm64_na
for details on how that is.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH V5 9/9] doc: board: ti: am62x_sk: Add A53 SPL DDR layout

On Wed, Jun 21, 2023 at 03:51:18PM +0530, Nikhil M Jain wrote:

> To understand usage of DDR in A53 SPL stage, add a table showing region
> and space used by major components of SPL.
> 
> Signed-off-by: Nikhil M Jain 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: mach-omap2: am33xx: musb: Fix condition for USB device definition

On Wed, Jun 21, 2023 at 05:56:56PM +0200, Julien Panis wrote:
> This patch fixes a bad condition for USB device definition.
> This prevents from getting a "No USB device found" error.
> 
> Fixes: 6815a66ad7430 ("am33xx: musb: Remove unused configuration logic")
> Signed-off-by: Julien Panis 
> ---
> This patch fixes a bad condition which leads to
> 'no USB device found' error, in usb_ether_init()
> function for instance.
> ---
>  arch/arm/mach-omap2/am33xx/board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/am33xx/board.c 
> b/arch/arm/mach-omap2/am33xx/board.c
> index ecc0a592e993..000c0d7712f9 100644
> --- a/arch/arm/mach-omap2/am33xx/board.c
> +++ b/arch/arm/mach-omap2/am33xx/board.c
> @@ -208,7 +208,7 @@ int cpu_mmc_init(struct bd_info *bis)
>  
>  /* AM33XX has two MUSB controllers which can be host or gadget */
>  #if (defined(CONFIG_AM335X_USB0) || defined(CONFIG_AM335X_USB1)) && \
> - defined(CONFIG_SPL_BUILD)
> + !defined(CONFIG_SPL_BUILD)
>  
>  static struct musb_hdrc_config musb_config = {
>   .multipoint = 1,

Well, that's just going to break USB networking in SPL, which is
supposed to be the only case for this code.  It's been a while since I
poked at this particular part of the code and board, is the gadget port
one with a "normal" mini port, or do we need one of the USB A <-> USB A
cables for it?  My general recollection of when I did 6815a66ad7430 was
that the device tree should control the ports in U-Boot itself.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] arm: mach-omap2: am33xx: musb: Fix condition for USB device definition

2023-06-21 Thread Julien Panis

This patch fixes a bad condition for USB device definition.
This prevents from getting a "No USB device found" error.

Fixes: 6815a66ad7430 ("am33xx: musb: Remove unused configuration logic")
Signed-off-by: Julien Panis 
---
This patch fixes a bad condition which leads to
'no USB device found' error, in usb_ether_init()
function for instance.
---
 arch/arm/mach-omap2/am33xx/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c 
b/arch/arm/mach-omap2/am33xx/board.c
index ecc0a592e993..000c0d7712f9 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -208,7 +208,7 @@ int cpu_mmc_init(struct bd_info *bis)
 
 /* AM33XX has two MUSB controllers which can be host or gadget */
 #if (defined(CONFIG_AM335X_USB0) || defined(CONFIG_AM335X_USB1)) && \
-   defined(CONFIG_SPL_BUILD)
+   !defined(CONFIG_SPL_BUILD)
 
 static struct musb_hdrc_config musb_config = {
.multipoint = 1,

---
base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f
change-id: 20230621-fix_usb_ether_init-4bf4f1135113

Best regards,
-- 
Julien Panis

[PATCH v1 2/2] meson-a1: dts: add ao secure node

2023-06-21 Thread Alexey Romanov

ao-secure node can be used to get information about the board,
so, for example, using show_board_info() we can get following
information for board with Meson A1 SoC:

SoC: Amlogic Meson A1 (A113L) Revision 2c:a (1:a)

Signed-off-by: Alexey Romanov 
---
 arch/arm/dts/meson-a1.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index 1f57c137384..149cc0e23a3 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -145,6 +145,12 @@
compatible = "amlogic,meson-rng";
reg = <0x0 0x5118 0x0 0x4>;
};
+
+   sec_AO: ao-secure@5a20 {
+   compatible = "amlogic,meson-gx-ao-secure", 
"syscon";
+   reg = <0x0 0x5a20 0x0 0x140>;
+   amlogic,has-chip-id;
+   };
};
 
gic: interrupt-controller@ff901000 {
-- 
2.38.1

[PATCH v1 1/2] meson-a1: dts: add hw rng node

2023-06-21 Thread Alexey Romanov

Add support for hardware random number generator
of Amlogic Meson SoCs.

Signed-off-by: Alexey Romanov 
---
 arch/arm/dts/meson-a1.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index f3560cbc3a4..1f57c137384 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -140,6 +140,11 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+   hwrng: rng@5118 {
+   compatible = "amlogic,meson-rng";
+   reg = <0x0 0x5118 0x0 0x4>;
+   };
};
 
gic: interrupt-controller@ff901000 {
-- 
2.38.1

[PATCH next v3 2/2] rockchip: puma: pass platform parameter to TF-A

2023-06-21 Thread Quentin Schulz

From: Quentin Schulz 

Puma supports upstream TF-A and is configured to output serial on UART0
instead of the default UART2. Since U-Boot is properly configured to
output on UART0, let's pass the DT to TF-A so there is no need for a
custom TF-A to make the latter output to UART0 too.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 configs/puma-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 697f5eccef5..b632fa3dcf3 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -39,7 +39,6 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_I2C=y
 CONFIG_SPL_POWER=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y

-- 
2.41.0

[PATCH next v3 1/2] rockchip: rk3399: pass platform parameter to TF-A by default for new RK3399 boards

2023-06-21 Thread Quentin Schulz

From: Quentin Schulz 

Long are gone the times TF-A couldn't handle the FDT passed by U-Boot.
Specifically, since commit e7b586987c0a ("rockchip: don't crash if we
get an FDT we can't parse") in TF-A, failure to parse the FDT will use
the fallback mechanism. This patch was merged in TF-A v2.4-rc0 from two
years ago.

New boards should likely have this option disabled or explicitly enable
it in their respective defconfig.

Because existing boards might depend on a TF-A version that predates
v2.4, let's just enable this option in all RK3399 defconfigs.
Maintainers of each board can decide for themselves if they would prefer
to disable this option and allow U-Boot to pass the DT to TF-A.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 arch/arm/mach-rockchip/Kconfig   | 1 -
 configs/chromebook_bob_defconfig | 1 +
 configs/chromebook_kevin_defconfig   | 1 +
 configs/eaidk-610-rk3399_defconfig   | 1 +
 configs/evb-rk3399_defconfig | 1 +
 configs/ficus-rk3399_defconfig   | 1 +
 configs/firefly-rk3399_defconfig | 1 +
 configs/khadas-edge-captain-rk3399_defconfig | 1 +
 configs/khadas-edge-rk3399_defconfig | 1 +
 configs/khadas-edge-v-rk3399_defconfig   | 1 +
 configs/leez-rk3399_defconfig| 1 +
 configs/nanopc-t4-rk3399_defconfig   | 1 +
 configs/nanopi-m4-2gb-rk3399_defconfig   | 1 +
 configs/nanopi-m4-rk3399_defconfig   | 1 +
 configs/nanopi-m4b-rk3399_defconfig  | 1 +
 configs/nanopi-neo4-rk3399_defconfig | 1 +
 configs/nanopi-r4s-rk3399_defconfig  | 1 +
 configs/orangepi-rk3399_defconfig| 1 +
 configs/pinebook-pro-rk3399_defconfig| 1 +
 configs/pinephone-pro-rk3399_defconfig   | 1 +
 configs/puma-rk3399_defconfig| 1 +
 configs/roc-pc-mezzanine-rk3399_defconfig| 1 +
 configs/roc-pc-rk3399_defconfig  | 1 +
 configs/rock-4c-plus-rk3399_defconfig| 1 +
 configs/rock-pi-4-rk3399_defconfig   | 1 +
 configs/rock-pi-4c-rk3399_defconfig  | 1 +
 configs/rock-pi-n10-rk3399pro_defconfig  | 1 +
 configs/rock960-rk3399_defconfig | 1 +
 configs/rockpro64-rk3399_defconfig   | 1 +
 29 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 9d6d20bf8ed..edc413d12a0 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -250,7 +250,6 @@ config ROCKCHIP_RK3399
imply PRE_CONSOLE_BUFFER
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_SDRAM_COMMON
-   imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
imply SPL_ROCKCHIP_COMMON_BOARD
imply TPL_SERIAL
imply TPL_LIBCOMMON_SUPPORT
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index dd6d4069a60..1807e838223 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -43,6 +43,7 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 3d2642f0d07..638beee2c6d 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -44,6 +44,7 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/eaidk-610-rk3399_defconfig 
b/configs/eaidk-610-rk3399_defconfig
index b4112a14712..77edbdbf959 100644
--- a/configs/eaidk-610-rk3399_defconfig
+++ b/configs/eaidk-610-rk3399_defconfig
@@ -26,6 +26,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index f594f15b3f8..5740ffc38f6 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index 94b8f88a965..90b07d847cc 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -27,6 +27,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x1
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_M

[PATCH next v3 0/2] rockchip: rk3399: pass platform parameter to TF-A

2023-06-21 Thread Quentin Schulz

Finally pass the FDT address to TF-A since it now gracefully fallbacks to
hardcoded defaults if it cannot parse it. This allows us to avoid modifying
hardcoded values in TF-A to enable the console.

This was tested with TF-A v2.9.0 on Puma Haikou RK3399.

We do this only for new RK3399 boards, where this will be a conscious choice to
enable CONFIG_SPL_ATF_NO_PLATFORM_PARAM, and Puma since it's been tested with
upstream TF-A. The imply condition on SPL_ATF is always true because SPL_ATF is
selected for all RK3399-based boards in arch/arm/mach-rockchip/Kconfig.

For board maintainers who received this mail, this patch series does not modify
anything for your board. However, this highlights that your board does not make
use of a feature (passing U-Boot DTB to TF-A) I find useful. I know this has
been a pain point for some of you since TF-A has a default baudrate of 115200 on
UART2 for its debug console which meant you had the choice of:
 1) patch TF-A to run at 150 baudrate instead (Rockchip's BSP default)
and/or a different UART controller than UART2,
 2) not have TF-A output,

You're now aware there's a third choice: disable SPL_ATF_NO_PLATFORM_PARAM
Kconfig option if your TF-A is of version 2.4 or newer. Up to you to send a
patch for your board defconfig.

This option was not disabled on all platforms on purpose since Kever prefers to
be careful since some boards might require downstream/blob-only TF-A that are
older than 2.4 version.

Signed-off-by: Quentin Schulz 
---
Changes in v3:
- rebased on top of master
- tested with TF-A v2.9.0 on Puma
- changed defconfigs for new RK3399 boards since v2
- Link to v2: 
https://lore.kernel.org/r/20221114-rk3399-tf-a-plat-param-v2-0-29287f1a5...@theobroma-systems.com

Changes in v2:
- keep the option selected for existing boards except Puma,
- added board maintainers to recipients of this mail,
- Link to v1: 
https://lore.kernel.org/r/20221114-rk3399-tf-a-plat-param-v1-0-0f873897b...@theobroma-systems.com

---
Quentin Schulz (2):
  rockchip: rk3399: pass platform parameter to TF-A by default for new 
RK3399 boards
  rockchip: puma: pass platform parameter to TF-A

 arch/arm/mach-rockchip/Kconfig   | 1 -
 configs/chromebook_bob_defconfig | 1 +
 configs/chromebook_kevin_defconfig   | 1 +
 configs/eaidk-610-rk3399_defconfig   | 1 +
 configs/evb-rk3399_defconfig | 1 +
 configs/ficus-rk3399_defconfig   | 1 +
 configs/firefly-rk3399_defconfig | 1 +
 configs/khadas-edge-captain-rk3399_defconfig | 1 +
 configs/khadas-edge-rk3399_defconfig | 1 +
 configs/khadas-edge-v-rk3399_defconfig   | 1 +
 configs/leez-rk3399_defconfig| 1 +
 configs/nanopc-t4-rk3399_defconfig   | 1 +
 configs/nanopi-m4-2gb-rk3399_defconfig   | 1 +
 configs/nanopi-m4-rk3399_defconfig   | 1 +
 configs/nanopi-m4b-rk3399_defconfig  | 1 +
 configs/nanopi-neo4-rk3399_defconfig | 1 +
 configs/nanopi-r4s-rk3399_defconfig  | 1 +
 configs/orangepi-rk3399_defconfig| 1 +
 configs/pinebook-pro-rk3399_defconfig| 1 +
 configs/pinephone-pro-rk3399_defconfig   | 1 +
 configs/roc-pc-mezzanine-rk3399_defconfig| 1 +
 configs/roc-pc-rk3399_defconfig  | 1 +
 configs/rock-4c-plus-rk3399_defconfig| 1 +
 configs/rock-pi-4-rk3399_defconfig   | 1 +
 configs/rock-pi-4c-rk3399_defconfig  | 1 +
 configs/rock-pi-n10-rk3399pro_defconfig  | 1 +
 configs/rock960-rk3399_defconfig | 1 +
 configs/rockpro64-rk3399_defconfig   | 1 +
 28 files changed, 27 insertions(+), 1 deletion(-)
---
base-commit: 50842b217fef505a0ec6662cc2acdc55d0bb23c5
change-id: 20221114-rk3399-tf-a-plat-param-3ab055f40b9e

Best regards,
-- 
Quentin Schulz

[PATCH v2 0/3] riscv: Add ACLINT mtimer and mswi devices support

This RISC-V ACLINT specification [1] defines a set of memory mapped
devices which provide inter-processor interrupts (IPI) and timer
functionalities for each HART on a multi-HART RISC-V platform.

This seriesl updates U-Boot existing SiFive CLINT driver to handle
the ACLINT changes, and is now able to support both CLINT and ACLINT.

With this series, U-Boot is able to boot on:

- QEMU 'virt' machine with 'aclint=on'
- Rocket Chip with ACLINT changes [2]

[1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
[2] https://github.com/chipsalliance/rocket-chip/pull/3330

Changes in v2:
- drop ae350.h changes

Bin Meng (3):
  riscv: timer: Update the sifive clint timer driver to support aclint
  riscv: clint: Update the sifive clint ipi driver to support aclint
  riscv: Rename SiFive CLINT to RISC-V ALINT

 MAINTAINERS   |  2 +-
 arch/riscv/Kconfig| 12 ++-
 arch/riscv/cpu/fu540/Kconfig  |  2 +-
 arch/riscv/cpu/fu740/Kconfig  |  2 +-
 arch/riscv/cpu/generic/Kconfig|  4 +-
 arch/riscv/cpu/jh7110/Kconfig |  2 +-
 arch/riscv/include/asm/global_data.h  |  4 +-
 arch/riscv/include/asm/syscon.h   |  2 +-
 arch/riscv/lib/Makefile   |  2 +-
 .../lib/{sifive_clint.c => aclint_ipi.c}  | 31 ++--
 board/openpiton/riscv64/Kconfig   |  2 +-
 board/sipeed/maix/Kconfig |  2 +-
 drivers/timer/Makefile|  2 +-
 drivers/timer/riscv_aclint_timer.c| 74 +++
 drivers/timer/sifive_clint_timer.c| 68 -
 include/configs/qemu-riscv.h  |  2 +-
 include/configs/sifive-unleashed.h|  2 +-
 include/configs/starfive-visionfive2.h|  1 +
 18 files changed, 123 insertions(+), 93 deletions(-)
 rename arch/riscv/lib/{sifive_clint.c => aclint_ipi.c} (53%)
 create mode 100644 drivers/timer/riscv_aclint_timer.c
 delete mode 100644 drivers/timer/sifive_clint_timer.c

-- 
2.25.1

[PATCH v2 3/3] riscv: Rename SiFive CLINT to RISC-V ALINT

As the RISC-V ACLINT specification is defined to be backward compatible
with the SiFive CLINT specification, we rename SiFive CLINT to RISC-V
ALINT in the source tree to be future-proof.

Signed-off-by: Bin Meng 
Reviewed-by: Rick Chen 

---

(no changes since v1)

 MAINTAINERS   |  2 +-
 arch/riscv/Kconfig|  8 
 arch/riscv/cpu/fu540/Kconfig  |  2 +-
 arch/riscv/cpu/fu740/Kconfig  |  2 +-
 arch/riscv/cpu/generic/Kconfig|  4 ++--
 arch/riscv/cpu/jh7110/Kconfig |  2 +-
 arch/riscv/include/asm/global_data.h  |  4 ++--
 arch/riscv/include/asm/syscon.h   |  2 +-
 arch/riscv/lib/Makefile   |  2 +-
 .../lib/{sifive_clint.c => aclint_ipi.c}  | 16 +++
 board/openpiton/riscv64/Kconfig   |  2 +-
 board/sipeed/maix/Kconfig |  2 +-
 drivers/timer/Makefile|  2 +-
 ...ive_clint_timer.c => riscv_aclint_timer.c} | 20 +--
 14 files changed, 35 insertions(+), 35 deletions(-)
 rename arch/riscv/lib/{sifive_clint.c => aclint_ipi.c} (73%)
 rename drivers/timer/{sifive_clint_timer.c => riscv_aclint_timer.c} (75%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 228d8af433..91f125aed0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1328,7 +1328,7 @@ F:doc/arch/riscv.rst
 F: doc/usage/sbi.rst
 F: drivers/sysreset/sysreset_sbi.c
 F: drivers/timer/andes_plmt_timer.c
-F: drivers/timer/sifive_clint_timer.c
+F: drivers/timer/riscv_aclint_timer.c
 F: tools/prelink-riscv.c
 
 RISC-V CANAAN KENDRYTE K210
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 9fcdd8c451..de7d5a9549 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -185,22 +185,22 @@ config DMA_ADDR_T_64BIT
bool
default y if 64BIT
 
-config SIFIVE_CLINT
+config RISCV_ACLINT
bool
depends on RISCV_MMODE
select REGMAP
select SYSCON
help
- The SiFive CLINT block holds memory-mapped control and status 
registers
+ The RISC-V ACLINT block holds memory-mapped control and status 
registers
  associated with software and timer interrupts.
 
-config SPL_SIFIVE_CLINT
+config SPL_RISCV_ACLINT
bool
depends on SPL_RISCV_MMODE
select SPL_REGMAP
select SPL_SYSCON
help
- The SiFive CLINT block holds memory-mapped control and status 
registers
+ The RISC-V ACLINT block holds memory-mapped control and status 
registers
  associated with software and timer interrupts.
 
 config SIFIVE_CACHE
diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index 1604b412b4..c68209d8fb 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -11,7 +11,7 @@ config SIFIVE_FU540
imply CPU
imply CPU_RISCV
imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
-   imply SPL_SIFIVE_CLINT
+   imply SPL_RISCV_ACLINT
imply CMD_CPU
imply SPL_CPU
imply SPL_OPENSBI
diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
index 3e0c1fddc8..d7ca968717 100644
--- a/arch/riscv/cpu/fu740/Kconfig
+++ b/arch/riscv/cpu/fu740/Kconfig
@@ -11,7 +11,7 @@ config SIFIVE_FU740
imply CPU
imply CPU_RISCV
imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
-   imply SPL_SIFIVE_CLINT
+   imply SPL_RISCV_ACLINT
imply CMD_CPU
imply SPL_CPU
imply SPL_OPENSBI
diff --git a/arch/riscv/cpu/generic/Kconfig b/arch/riscv/cpu/generic/Kconfig
index e025134b23..897765c3c6 100644
--- a/arch/riscv/cpu/generic/Kconfig
+++ b/arch/riscv/cpu/generic/Kconfig
@@ -9,8 +9,8 @@ config GENERIC_RISCV
imply CPU
imply CPU_RISCV
imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
-   imply SIFIVE_CLINT if RISCV_MMODE
-   imply SPL_SIFIVE_CLINT if SPL_RISCV_MMODE
+   imply RISCV_ACLINT if RISCV_MMODE
+   imply SPL_RISCV_ACLINT if SPL_RISCV_MMODE
imply CMD_CPU
imply SPL_CPU
imply SPL_OPENSBI
diff --git a/arch/riscv/cpu/jh7110/Kconfig b/arch/riscv/cpu/jh7110/Kconfig
index 3f145415eb..4d9581165b 100644
--- a/arch/riscv/cpu/jh7110/Kconfig
+++ b/arch/riscv/cpu/jh7110/Kconfig
@@ -25,4 +25,4 @@ config STARFIVE_JH7110
imply SPL_CPU
imply SPL_LOAD_FIT
imply SPL_OPENSBI
-   imply SPL_SIFIVE_CLINT
+   imply SPL_RISCV_ACLINT
diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index 31ba72693d..9d97517e12 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -18,8 +18,8 @@
 struct arch_global_data {
long boot_hart; /* boot hart id */
phys_addr_t firmware_fdt_addr;
-#if CONFIG_IS_ENABLED(SIFIVE_CLINT)
-   void __iomem *clint;/* clint base address */
+#if CONFIG_IS_ENABL

[PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to support aclint

This RISC-V ACLINT specification [1] defines a set of memory mapped
devices which provide inter-processor interrupts (IPI) and timer
functionalities for each HART on a multi-HART RISC-V platform.

The RISC-V ACLINT specification is defined to be backward compatible
with the SiFive CLINT specification, however the device tree binding
is a new one. This change updates the sifive clint timer driver to
support ACLINT mtimer device, using a per-driver data field to hold
the mtimer offset to the base address encoded in the mtimer node.

[1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc

Signed-off-by: Bin Meng 

---

Changes in v2:
- drop ae350.h changes

 drivers/timer/sifive_clint_timer.c | 16 +++-
 include/configs/qemu-riscv.h   |  2 +-
 include/configs/sifive-unleashed.h |  2 +-
 include/configs/starfive-visionfive2.h |  1 +
 4 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/timer/sifive_clint_timer.c 
b/drivers/timer/sifive_clint_timer.c
index 939b99d937..be45f17ddf 100644
--- a/drivers/timer/sifive_clint_timer.c
+++ b/drivers/timer/sifive_clint_timer.c
@@ -12,12 +12,16 @@
 #include 
 #include 
 
+#define CLINT_MTIME_OFFSET 0xbff8
+#define ACLINT_MTIME_OFFSET0
+
 /* mtime register */
-#define MTIME_REG(base)((ulong)(base) + 0xbff8)
+#define MTIME_REG(base, offset)((ulong)(base) + (offset))
 
 static u64 notrace sifive_clint_get_count(struct udevice *dev)
 {
-   return readq((void __iomem *)MTIME_REG(dev_get_priv(dev)));
+   return readq((void __iomem *)MTIME_REG(dev_get_priv(dev),
+  dev_get_driver_data(dev)));
 }
 
 #if CONFIG_IS_ENABLED(RISCV_MMODE) && IS_ENABLED(CONFIG_TIMER_EARLY)
@@ -35,7 +39,8 @@ unsigned long notrace timer_early_get_rate(void)
  */
 u64 notrace timer_early_get_count(void)
 {
-   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
+   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE,
+  RISCV_MMODE_TIMEROFF));
 }
 #endif
 
@@ -53,8 +58,9 @@ static int sifive_clint_probe(struct udevice *dev)
 }
 
 static const struct udevice_id sifive_clint_ids[] = {
-   { .compatible = "riscv,clint0" },
-   { .compatible = "sifive,clint0" },
+   { .compatible = "riscv,clint0", .data = CLINT_MTIME_OFFSET },
+   { .compatible = "sifive,clint0", .data = CLINT_MTIME_OFFSET },
+   { .compatible = "riscv,aclint-mtimer", .data = ACLINT_MTIME_OFFSET },
{ }
 };
 
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
index 20135f569e..f6d326bda0 100644
--- a/include/configs/qemu-riscv.h
+++ b/include/configs/qemu-riscv.h
@@ -11,8 +11,8 @@
 #define CFG_SYS_SDRAM_BASE 0x8000
 
 #define RISCV_MMODE_TIMERBASE  0x200
+#define RISCV_MMODE_TIMEROFF   0xbff8
 #define RISCV_MMODE_TIMER_FREQ 100
-
 #define RISCV_SMODE_TIMER_FREQ 100
 
 /* Environment options */
diff --git a/include/configs/sifive-unleashed.h 
b/include/configs/sifive-unleashed.h
index de3a0dcdd5..f208f5e20d 100644
--- a/include/configs/sifive-unleashed.h
+++ b/include/configs/sifive-unleashed.h
@@ -14,8 +14,8 @@
 #define CFG_SYS_SDRAM_BASE 0x8000
 
 #define RISCV_MMODE_TIMERBASE  0x200
+#define RISCV_MMODE_TIMEROFF   0xbff8
 #define RISCV_MMODE_TIMER_FREQ 100
-
 #define RISCV_SMODE_TIMER_FREQ 100
 
 /* Environment options */
diff --git a/include/configs/starfive-visionfive2.h 
b/include/configs/starfive-visionfive2.h
index 93dcc22d36..4ee02b8420 100644
--- a/include/configs/starfive-visionfive2.h
+++ b/include/configs/starfive-visionfive2.h
@@ -9,6 +9,7 @@
 #define _STARFIVE_VISIONFIVE2_H
 
 #define RISCV_MMODE_TIMERBASE  0x200
+#define RISCV_MMODE_TIMEROFF   0xbff8
 #define RISCV_MMODE_TIMER_FREQ 400
 #define RISCV_SMODE_TIMER_FREQ 400
 
-- 
2.25.1

[PATCH v2 2/3] riscv: clint: Update the sifive clint ipi driver to support aclint

This RISC-V ACLINT specification [1] defines a set of memory mapped
devices which provide inter-processor interrupts (IPI) and timer
functionalities for each HART on a multi-HART RISC-V platform.

The RISC-V ACLINT specification is defined to be backward compatible
with the SiFive CLINT specification, however the device tree binding
is a new one. This change updates the sifive clint ipi driver to
support ACLINT mswi device, by checking the per-driver data field of
the ACLINT mtimer driver to determine whether a syscon based approach
needs to be taken to get the base address of the ACLINT mswi device.

[1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc

Signed-off-by: Bin Meng 
Reviewed-by: Rick Chen 
---

(no changes since v1)

 arch/riscv/Kconfig|  4 
 arch/riscv/lib/sifive_clint.c | 21 -
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index f6ed05906a..9fcdd8c451 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -188,6 +188,8 @@ config DMA_ADDR_T_64BIT
 config SIFIVE_CLINT
bool
depends on RISCV_MMODE
+   select REGMAP
+   select SYSCON
help
  The SiFive CLINT block holds memory-mapped control and status 
registers
  associated with software and timer interrupts.
@@ -195,6 +197,8 @@ config SIFIVE_CLINT
 config SPL_SIFIVE_CLINT
bool
depends on SPL_RISCV_MMODE
+   select SPL_REGMAP
+   select SPL_SYSCON
help
  The SiFive CLINT block holds memory-mapped control and status 
registers
  associated with software and timer interrupts.
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index ab22395c55..f242168381 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -10,9 +10,12 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* MSIP registers */
@@ -30,7 +33,11 @@ int riscv_init_ipi(void)
if (ret)
return ret;
 
-   gd->arch.clint = dev_read_addr_ptr(dev);
+   if (dev_get_driver_data(dev) != 0)
+   gd->arch.clint = dev_read_addr_ptr(dev);
+   else
+   gd->arch.clint = syscon_get_first_range(RISCV_SYSCON_CLINT);
+
if (!gd->arch.clint)
return -EINVAL;
 
@@ -57,3 +64,15 @@ int riscv_get_ipi(int hart, int *pending)
 
return 0;
 }
+
+static const struct udevice_id riscv_aclint_swi_ids[] = {
+   { .compatible = "riscv,aclint-mswi", .data = RISCV_SYSCON_CLINT },
+   { }
+};
+
+U_BOOT_DRIVER(riscv_aclint_swi) = {
+   .name   = "riscv_aclint_swi",
+   .id = UCLASS_SYSCON,
+   .of_match   = riscv_aclint_swi_ids,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
-- 
2.25.1

[PATCH] riscv: Fix alignment of RELA sections in the linker scripts

In current linker script both .efi_runtime_rel and .rela.dyn sections
are of RELA type whose entry size is either 12 (RV32) or 24 (RV64).
These two are arranged as an continuous region on purpose so that the
prelink-riscv executable can fix up the PIE addresses in one loop.

However there is an 'ALIGN(8)' between these 2 sections which might
cause a gap to be inserted between thesse 2 sections to satify the
alignment requirement on RV32. This would break the assumption of
the prelink process and generate an unbootable image.

Fixes: 9a6569a043d3 ("riscv: Update alignment for some sections in linker 
scripts")
Signed-off-by: Bin Meng 

---
This fix should go into the v2023.07 release.

 arch/riscv/cpu/u-boot.lds | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds
index 15b5cbc585..2ffe6ba3c8 100644
--- a/arch/riscv/cpu/u-boot.lds
+++ b/arch/riscv/cpu/u-boot.lds
@@ -48,7 +48,7 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}
 
-   . = ALIGN(4);
+   . = ALIGN(8);
 
.efi_runtime_rel : {
__efi_runtime_rel_start = .;
@@ -57,8 +57,6 @@ SECTIONS
__efi_runtime_rel_stop = .;
}
 
-   . = ALIGN(8);
-
/DISCARD/ : { *(.rela.plt*) }
.rela.dyn : {
__rel_dyn_start = .;
-- 
2.25.1

[PULL] u-boot-usb/master

The following changes since commit 50842b217fef505a0ec6662cc2acdc55d0bb23c5:

  Merge tag 'u-boot-at91-fixes-2023.07-a' of 
https://source.denx.de/u-boot/custodians/u-boot-at91 (2023-06-19 09:18:40 -0400)

are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to 9c9454ac2e4ffd9a8b30744329029f1676d2e7be:

  usb: dwc2: Fix the write to W1C fields in HPRT register (2023-06-21 13:15:58 
+0200)


Teik Heng Chong (1):
  usb: dwc2: Fix the write to W1C fields in HPRT register

Xavier Drudis Ferran (1):
  cmd: usb: Prevent reset in usb tree/info command

 cmd/usb.c   |  8 ++--
 drivers/usb/host/dwc2.c | 34 --
 drivers/usb/host/dwc2.h |  4 
 3 files changed, 18 insertions(+), 28 deletions(-)

Re: [PATCH v1] cache_v8: agilex5: Disable Dcache in the SPL


On 6/21/23 16:15, Marc Zyngier wrote:

On Wed, 21 Jun 2023 15:06:51 +0100,
Jit Loon Lim  wrote:


From: Kah Jing Lee 

Dcache feature is not enabled in SPL and enable it will cause ISR
exception. Since the Dcache is not supported in SPL, new
CONFIG_SPL_SYS_DISABLE_DCACHE_OPS is added to Kconfig to disable Dcache
in SPL.

Signed-off-by: Kah Jing Lee 


This is missing your own SoB.

Now, I'd like to understand what you are actually trying to fix. What
is this 'ISR' exception? This isn't something the architecture
describes. Unless you are using CMOs on something that isn't memory or
for which you don't have a mapping, this should never generate an
exception.


You beat me to it, indeed, thanks !

Re: [PATCH v1] cache_v8: agilex5: Disable Dcache in the SPL


On 6/21/23 16:06, Jit Loon Lim wrote:

From: Kah Jing Lee 

Dcache feature is not enabled in SPL and enable it will cause ISR
exception


Why would it cause an exception ?

Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state


On 6/21/23 16:11, Jit Loon Lim wrote:

From: Teik Heng Chong 

The controller registers should not be accessed while the controller's
vcc_reset_n is asserted.

Signed-off-by: Teik Heng Chong 


Is this patch ported from Linux or is this custom development ?

Is there a matching patch/fix in Linux already ?

Re: [PATCH v1] cache_v8: agilex5: Disable Dcache in the SPL

2023-06-21 Thread Marc Zyngier

On Wed, 21 Jun 2023 15:06:51 +0100,
Jit Loon Lim  wrote:
> 
> From: Kah Jing Lee 
> 
> Dcache feature is not enabled in SPL and enable it will cause ISR
> exception. Since the Dcache is not supported in SPL, new
> CONFIG_SPL_SYS_DISABLE_DCACHE_OPS is added to Kconfig to disable Dcache
> in SPL.
> 
> Signed-off-by: Kah Jing Lee 

This is missing your own SoB.

Now, I'd like to understand what you are actually trying to fix. What
is this 'ISR' exception? This isn't something the architecture
describes. Unless you are using CMOs on something that isn't memory or
for which you don't have a mapping, this should never generate an
exception.

Thanks,

M.

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

[PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state

From: Teik Heng Chong 

The controller registers should not be accessed while the controller's
vcc_reset_n is asserted.

Signed-off-by: Teik Heng Chong 
---
 drivers/usb/host/xhci-dwc3.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 1dbd65dfaa..3172956bd6 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -227,6 +227,11 @@ static int xhci_dwc3_probe(struct udevice *dev)
 static int xhci_dwc3_remove(struct udevice *dev)
 {
struct xhci_dwc3_plat *plat = dev_get_plat(dev);
+   int ret;
+
+   ret = xhci_deregister(dev);
+   if (ret)
+   return ret;
 
dwc3_shutdown_phy(dev, &plat->phys);
 
@@ -234,7 +239,7 @@ static int xhci_dwc3_remove(struct udevice *dev)
 
reset_release_bulk(&plat->resets);
 
-   return xhci_deregister(dev);
+   return 0;
 }
 
 static const struct udevice_id xhci_dwc3_ids[] = {
-- 
2.26.2

[PATCH v1] cache_v8: agilex5: Disable Dcache in the SPL

From: Kah Jing Lee 

Dcache feature is not enabled in SPL and enable it will cause ISR
exception. Since the Dcache is not supported in SPL, new
CONFIG_SPL_SYS_DISABLE_DCACHE_OPS is added to Kconfig to disable Dcache
in SPL.

Signed-off-by: Kah Jing Lee 
---
 arch/arm/cpu/armv8/cache_v8.c | 20 +++-
 common/spl/Kconfig|  7 +++
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cb1131a048..7f25d3a6ce 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -534,29 +534,31 @@ inline void flush_dcache_all(void)
 #endif
 }
 
-#ifndef CONFIG_SYS_DISABLE_DCACHE_OPS
-/*
- * Invalidates range in all levels of D-cache/unified cache
- */
+#if CONFIG_IS_ENABLED(SYS_DISABLE_DCACHE_OPS) || \
+   CONFIG_IS_ENABLED(SPL_SYS_DISABLE_DCACHE_OPS) && \
+   CONFIG_IS_ENABLED(SPL_BUILD)
 void invalidate_dcache_range(unsigned long start, unsigned long stop)
 {
-   __asm_invalidate_dcache_range(start, stop);
 }
 
-/*
- * Flush range(clean & invalidate) from all levels of D-cache/unified cache
- */
 void flush_dcache_range(unsigned long start, unsigned long stop)
 {
-   __asm_flush_dcache_range(start, stop);
 }
 #else
+/*
+ * Invalidates range in all levels of D-cache/unified cache
+ */
 void invalidate_dcache_range(unsigned long start, unsigned long stop)
 {
+   __asm_invalidate_dcache_range(start, stop);
 }
 
+/*
+ * Flush range(clean & invalidate) from all levels of D-cache/unified cache
+ */
 void flush_dcache_range(unsigned long start, unsigned long stop)
 {
+   __asm_flush_dcache_range(start, stop);
 }
 #endif /* CONFIG_SYS_DISABLE_DCACHE_OPS */
 
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 2c042ad306..7e458503df 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -19,6 +19,13 @@ config SPL
 menu "SPL configuration options"
depends on SPL
 
+config SPL_SYS_DISABLE_DCACHE_OPS
+   bool "Do not enable dcache operation in SPL"
+   depends on SPL
+   help
+ Do not enable data cache operation in SPL. This will turn off the
+ Dcache support and have the empty dcache declaration.
+
 config SPL_FRAMEWORK
bool "Support SPL based upon the common SPL framework"
default y
-- 
2.26.2

[PATCH v1] arm: socfpga: agilex5: Define MMU mapping region for FPGA

From: Sin Hui Kho 

Add MMU mapping region for FPGA including 512 MB LW HPS2FPGA and
1GB HPS2FPGA.

Signed-off-by: Sin Hui Kho 
---
 arch/arm/mach-socfpga/mmu-arm64_s10.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-socfpga/mmu-arm64_s10.c 
b/arch/arm/mach-socfpga/mmu-arm64_s10.c
index 0951233cad..c88f0e8632 100644
--- a/arch/arm/mach-socfpga/mmu-arm64_s10.c
+++ b/arch/arm/mach-socfpga/mmu-arm64_s10.c
@@ -36,6 +36,14 @@ static struct mm_region socfpga_agilex5_mem_map[] = {
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN,
}, {
+   /* FPGA 1.5GB */
+   .virt   = 0x2000UL,
+   .phys   = 0x2000UL,
+   .size   = 0x6000UL,
+   .attrs  = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+   PTE_BLOCK_NON_SHARE |
+   PTE_BLOCK_PXN | PTE_BLOCK_UXN,
+   },{
/* MEM 2GB */
.virt   = 0x8000UL,
.phys   = 0x8000UL,
-- 
2.26.2

[PATCH 1/2] dm: adc: add iMX93 ADC support

2023-06-21 Thread Luca Ellero

This commit adds driver for iMX93 ADC.

The driver is implemented using driver model and provides
ADC uclass's methods for ADC single channel operations:
- adc_start_channel()
- adc_channel_data()
- adc_stop()

ADC features:
- channels: 4
- resolution: 12-bit

Signed-off-by: Luca Ellero 
---
 drivers/adc/Kconfig |   8 ++
 drivers/adc/Makefile|   1 +
 drivers/adc/imx93-adc.c | 290 
 3 files changed, 299 insertions(+)
 create mode 100644 drivers/adc/imx93-adc.c

diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index e719c38bb3..4336732dee 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -63,3 +63,11 @@ config STM32_ADC
  - core driver to deal with common resources
  - child driver to deal with individual ADC resources (declare ADC
  device and associated channels, start/stop conversions)
+
+config ADC_IMX93
+   bool "Enable NXP IMX93 ADC driver"
+   help
+ This enables basic driver for NXP IMX93 ADC.
+ It provides:
+ - 4 analog input channels
+ - 12-bit resolution
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index c1387f3a34..5336c82097 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
 obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
 obj-$(CONFIG_SARADC_MESON) += meson-saradc.o
 obj-$(CONFIG_STM32_ADC) += stm32-adc.o stm32-adc-core.o
+obj-$(CONFIG_ADC_IMX93) += imx93-adc.o
diff --git a/drivers/adc/imx93-adc.c b/drivers/adc/imx93-adc.c
new file mode 100644
index 00..41d04e0426
--- /dev/null
+++ b/drivers/adc/imx93-adc.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 ASEM Srl
+ * Author: Luca Ellero 
+ *
+ * Originally based on NXP linux-imx kernel v5.15 drivers/iio/adc/imx93_adc.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX93_ADC_MCR  0x00
+#define IMX93_ADC_MSR  0x04
+#define IMX93_ADC_ISR  0x10
+#define IMX93_ADC_IMR  0x20
+#define IMX93_ADC_CIMR00x24
+#define IMX93_ADC_CTR0 0x94
+#define IMX93_ADC_NCMR00xA4
+#define IMX93_ADC_PCDR00x100
+#define IMX93_ADC_PCDR10x104
+#define IMX93_ADC_PCDR20x108
+#define IMX93_ADC_PCDR30x10c
+#define IMX93_ADC_PCDR40x110
+#define IMX93_ADC_PCDR50x114
+#define IMX93_ADC_PCDR60x118
+#define IMX93_ADC_PCDR70x11c
+#define IMX93_ADC_CALSTAT  0x39C
+
+#define IMX93_ADC_MCR_MODE_MASKBIT(29)
+#define IMX93_ADC_MCR_NSTART_MASK  BIT(24)
+#define IMX93_ADC_MCR_CALSTART_MASKBIT(14)
+#define IMX93_ADC_MCR_ADCLKSE_MASK BIT(8)
+#define IMX93_ADC_MCR_PWDN_MASKBIT(0)
+
+#define IMX93_ADC_MSR_CALFAIL_MASK BIT(30)
+#define IMX93_ADC_MSR_CALBUSY_MASK BIT(29)
+#define IMX93_ADC_MSR_ADCSTATUS_MASK   GENMASK(2, 0)
+
+#define IMX93_ADC_ISR_EOC_MASK BIT(1)
+
+#define IMX93_ADC_IMR_EOC_MASK BIT(1)
+#define IMX93_ADC_IMR_ECH_MASK BIT(0)
+
+#define IMX93_ADC_PCDR_CDATA_MASK  GENMASK(11, 0)
+
+#define IDLE   0
+#define POWER_DOWN 1
+#define WAIT_STATE 2
+#define BUSY_IN_CALIBRATION3
+#define SAMPLE 4
+#define CONVERSION 6
+
+#define IMX93_ADC_MAX_CHANNEL  3
+#define IMX93_ADC_DAT_MASK 0xfff
+#define IMX93_ADC_TIMEOUT  10
+
+struct imx93_adc_priv {
+   int active_channel;
+   void __iomem *regs;
+   struct clk ipg_clk;
+};
+
+static void imx93_adc_power_down(struct imx93_adc_priv *adc)
+{
+   u32 mcr, msr;
+   int ret;
+
+   mcr = readl(adc->regs + IMX93_ADC_MCR);
+   mcr |= FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+   writel(mcr, adc->regs + IMX93_ADC_MCR);
+
+   ret = readl_poll_timeout(adc->regs + IMX93_ADC_MSR, msr,
+   ((msr & IMX93_ADC_MSR_ADCSTATUS_MASK) == POWER_DOWN), 50);
+   if (ret == -ETIMEDOUT)
+   pr_warn("ADC not in power down mode, current MSR: %x\n", msr);
+}
+
+static void imx93_adc_power_up(struct imx93_adc_priv *adc)
+{
+   u32 mcr;
+
+   /* bring ADC out of power down state, in idle state */
+   mcr = readl(adc->regs + IMX93_ADC_MCR);
+   mcr &= ~FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+   writel(mcr, adc->regs + IMX93_ADC_MCR);
+}
+
+static void imx93_adc_config_ad_clk(struct imx93_adc_priv *adc)
+{
+   u32 mcr;
+
+   /* put adc in power down mode */
+   imx93_adc_power_down(adc);
+
+   /* config the AD_CLK equal to bus clock */
+   mcr = readl(adc->regs + IMX93_ADC_MCR);
+   mcr |= FIELD_P

[PATCH 2/2] imx93_evk: defconfig: add adc support

2023-06-21 Thread Luca Ellero

iMX93 ADC features:
- 4 channels
- 12 bit resolution

Signed-off-by: Luca Ellero 
---
 configs/imx93_11x11_evk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/imx93_11x11_evk_defconfig 
b/configs/imx93_11x11_evk_defconfig
index 89edebc4c6..30ef460c80 100644
--- a/configs/imx93_11x11_evk_defconfig
+++ b/configs/imx93_11x11_evk_defconfig
@@ -81,6 +81,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
+CONFIG_ADC_IMX93=y
 CONFIG_CPU=y
 CONFIG_CPU_IMX=y
 CONFIG_IMX_RGPIO2P=y
-- 
2.25.1

[PATCH v5 0/2 RESEND] imx93: add ADC support

2023-06-21 Thread Luca Ellero

Add ADC support for NXP iMX93

Changes for v2:
- add "static" to functions
- enable ADC in iMX93 EVK

Changes for v3:
- split in 3 commits
- keep dts file in sync with Linux devicetree
- add comments to commits

Changes for v4:
- add imx93_adc_power_down() in imx93_adc_stop()

Changes for v5:
- simplify code
- remove redundant code
- add clock handling

Luca Ellero (2):
  dm: adc: add iMX93 ADC support
  imx93_evk: defconfig: add adc support

 configs/imx93_11x11_evk_defconfig |   1 +
 drivers/adc/Kconfig   |   8 +
 drivers/adc/Makefile  |   1 +
 drivers/adc/imx93-adc.c   | 290 ++
 4 files changed, 300 insertions(+)
 create mode 100644 drivers/adc/imx93-adc.c

-- 
2.25.1

[PATCH v1] arch: arm: dts: Enable APB Timer for agilex5

From: Dinesh Maniyam 

Enable APB Timer driver model.

Signed-off-by: Dinesh Maniyam 
---
 arch/arm/dts/socfpga_agilex5_socdk.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/dts/socfpga_agilex5_socdk.dts 
b/arch/arm/dts/socfpga_agilex5_socdk.dts
index 1a39426561..59ff426983 100644
--- a/arch/arm/dts/socfpga_agilex5_socdk.dts
+++ b/arch/arm/dts/socfpga_agilex5_socdk.dts
@@ -121,6 +121,22 @@
status = "okay";
 };
 
+&timer0 {
+   status = "okay";
+};
+
+&timer1 {
+   status = "okay";
+};
+
+&timer2 {
+   status = "okay";
+};
+
+&timer3 {
+   status = "okay";
+};
+
 &spi0 {
status = "okay";
 };
-- 
2.26.2

[PATCH v1] drivers: rng: add check status bit feature

2023-06-21 Thread Alexey Romanov

For some Amlogic SOC's, the mechanism for obtain a random number
has been changed. For example, S4 now uses a status bit wait algo.

Signed-off-by: Alexey Romanov 
---
 drivers/rng/meson-rng.c | 73 +
 1 file changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/rng/meson-rng.c b/drivers/rng/meson-rng.c
index e0a1e8c7e04..3bf2eb9cf87 100644
--- a/drivers/rng/meson-rng.c
+++ b/drivers/rng/meson-rng.c
@@ -11,36 +11,82 @@
 #include 
 #include 
 
+struct meson_rng_data {
+   bool check_status_bit;
+};
+
 struct meson_rng_plat {
fdt_addr_t base;
struct clk clk;
+   struct meson_rng_data *data;
 };
 
+#define RETRY_CNT 100
+#define RNG_OUT_OFFSET 0x08
+
+#define SEED_READY_STS_BIT 0
+#define RUN_BIT 31
+
+static int meson_rng_wait_status(struct meson_rng_plat *pdata, int bit)
+{
+   u32 status;
+   u32 cnt = 0;
+
+   pr_debug("Poll status of bit: %d\n", bit);
+
+   do {
+   status = readl(pdata->base) & BIT(bit);
+   } while (status && (cnt++ < RETRY_CNT));
+
+   if (cnt == RETRY_CNT) {
+   pr_err("Can't get random number, try again");
+   return -EBUSY;
+   }
+
+   return 0;
+}
+
 /**
  * meson_rng_read() - fill buffer with random bytes
  *
  * @buffer:buffer to receive data
  * @size:  size of buffer
  *
- * Return: 0
+ * Return: 0 on success or -errno in failure
  */
 static int meson_rng_read(struct udevice *dev, void *data, size_t len)
 {
struct meson_rng_plat *pdata = dev_get_plat(dev);
+   struct meson_rng_data *rng_data = pdata->data;
char *buffer = (char *)data;
+   int err;
 
while (len) {
-   u32 rand = readl(pdata->base);
+   u32 rand;
size_t step;
 
-   if (len >= 4)
-   step = 4;
-   else
-   step = len;
+   if (rng_data->check_status_bit) {
+   writel(readl(pdata->base) | BIT(SEED_READY_STS_BIT), 
pdata->base);
+
+   err = meson_rng_wait_status(pdata, SEED_READY_STS_BIT);
+   if (err)
+   return err;
+
+   err = meson_rng_wait_status(pdata, RUN_BIT);
+   if (err)
+   return err;
+
+   rand = readl(pdata->base + RNG_OUT_OFFSET);
+   } else {
+   rand = readl(pdata->base);
+   }
+
+   step = min_t(u32, len, 4);
memcpy(buffer, &rand, step);
buffer += step;
len -= step;
}
+
return 0;
 }
 
@@ -90,6 +136,8 @@ static int meson_rng_of_to_plat(struct udevice *dev)
if (!pdata->base)
return -ENODEV;
 
+   pdata->data = (struct meson_rng_data *)dev_get_driver_data(dev);
+
/* Get optional "core" clock */
err = clk_get_by_name_optional(dev, "core", &pdata->clk);
if (err)
@@ -102,9 +150,22 @@ static const struct dm_rng_ops meson_rng_ops = {
.read = meson_rng_read,
 };
 
+static const struct meson_rng_data meson_rng_data = {
+   .check_status_bit = false,
+};
+
+static const struct meson_rng_data meson_rng_data_s4 = {
+   .check_status_bit = true,
+};
+
 static const struct udevice_id meson_rng_match[] = {
{
.compatible = "amlogic,meson-rng",
+   .data = (ulong)&meson_rng_data,
+   },
+   {
+   .compatible = "amlogic,meson-rng-s4",
+   .data = (ulong)&meson_rng_data_s4,
},
{},
 };
-- 
2.38.1

[PATCH] mmc:Remove the legacy mode clock setting operation

2023-06-21 Thread xf_hqu

From: xiefei 

Due to the need to read the register value before
switching to hs mode, the standard protocol does
not explicitly specify that the setting before
switching to hs mode is in legacy mode. Therefore,
the code at this point may cause communication
abnormalities between the host and card

Signed-off-by: xiefei 
---
 drivers/mmc/mmc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1af6af82e6..915f446973 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2138,7 +2138,6 @@ static int mmc_select_mode_and_width(struct mmc *mmc, 
uint card_caps)
mmc_set_card_speed(mmc, MMC_HS, true);
else
 #endif
-   mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
 
for_each_mmc_mode_by_pref(card_caps, mwt) {
for_each_supported_width(card_caps & mwt->widths,
-- 
2.17.1

Re: [PATCH 1/5] mkeficapsule: constify function parameters

2023-06-21 Thread Schmidt, Malte


Hello Heinrich,

thank you for you extensive review. I will incorporate
your reviews in a future version of the patch series.

Best Regards
Malte

Am 16.06.2023 um 20:18 schrieb Heinrich Schuchardt:

On 6/16/23 13:34, Stefan Herbrechtsmeier wrote:

From: Malte Schmidt 


Thanks for considering which parameters may be constants.

nits:

The Urban Dictionary defines 'constify' as:

"To constantly do something, like constantly watching anime all day."

%s/constify function parameters/make function parameters const/



Use const keyword for function parameters where appropriate.

Signed-off-by: Malte Schmidt 
Signed-off-by: Stefan Herbrechtsmeier 


---

  tools/mkeficapsule.c | 27 ---
  1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 52be1f122e..b8db00b16b 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -88,8 +88,8 @@ static void print_usage(void)
   * are filled in by create_auth_data().
   */
  struct auth_context {
-    char *key_file;
-    char *cert_file;
+    const char *key_file;
+    const char *cert_file;
  uint8_t *image_data;
  size_t image_size;
  struct efi_firmware_image_authentication auth;
@@ -112,7 +112,7 @@ static int dump_sig;
   * * 0  - on success
   * * -1 - on failure
   */
-static int read_bin_file(char *bin, uint8_t **data, off_t *bin_size)
+static int read_bin_file(const char *bin, uint8_t **data, off_t 
*bin_size)

  {
  FILE *g;
  struct stat bin_stat;
@@ -170,7 +170,8 @@ err:
   * * 0  - on success
   * * -1 - on failure
   */
-static int write_capsule_file(FILE *f, void *data, size_t size, 
const char *msg)

+static int write_capsule_file(FILE *f, const void *data, size_t size,


Why should size not be constant?

The name of the parameter 'size' does not match the function
documentation which has 'bin_size'. Please, change either of both.

Parameter 'f' does not match the documentation which has 'bin'.

For each function that you touch, please, ensure that the function
parameters are correctly documented.


+  const char *msg)
  {
  size_t size_written;

@@ -343,7 +344,8 @@ static int create_auth_data(struct auth_context 
*ctx)

   * * 0  - on success
   * * -1 - on failure
   */
-static int dump_signature(const char *path, uint8_t *signature, 
size_t sig_size)

+static int dump_signature(const char *path, const uint8_t *signature,
+  size_t sig_size)


Why should sig_size not be constant?


  {
  char *sig_path;
  FILE *f;
@@ -402,10 +404,12 @@ static void free_sig_data(struct auth_context 
*ctx)

   * * 0  - on success
   * * -1 - on failure
   */
-static int create_fwbin(char *path, char *bin, efi_guid_t *guid,
-    unsigned long index, unsigned long instance,
-    struct fmp_payload_header_params *fmp_ph_params,
-    uint64_t mcount, char *privkey_file, char *cert_file,
+static int create_fwbin(const char *path, const char *bin,
+    const efi_guid_t *guid, unsigned long index,
+    unsigned long instance,
+    const struct fmp_payload_header_params *fmp_ph_params,
+    uint64_t mcount,
+    const char *privkey_file, const char *cert_file,
  uint16_t oemflags)


Why shouldn't instance, mcount, oemflags be constant?


  {
  struct efi_capsule_header header;
@@ -604,7 +608,8 @@ void convert_uuid_to_guid(unsigned char *buf)
  buf[7] = c;
  }

-static int create_empty_capsule(char *path, efi_guid_t *guid, bool 
fw_accept)
+static int create_empty_capsule(const char *path, const efi_guid_t 
*guid,

+    bool fw_accept)


Why should fw_accept not be constant?

Please, make the use of 'const' a bit more consistent.

Best regards

Heinrich


  {
  struct efi_capsule_header header = { 0 };
  FILE *f = NULL;
@@ -666,7 +671,7 @@ int main(int argc, char **argv)
  unsigned long index, instance;
  uint64_t mcount;
  unsigned long oemflags;
-    char *privkey_file, *cert_file;
+    const char *privkey_file, *cert_file;
  int c, idx;
  struct fmp_payload_header_params fmp_ph_params = { 0 };

Re: [PATCH v2] cmd: usb: Prevent reset in usb tree/info command


On 6/21/23 09:13, Xavier Drudis Ferran wrote:


Commands causing reset in some configs:

When bootflow scan is run, this will cause a UCLASS_BOOTDEV device to
be added as sibling of those UCLASS_BLK devices found in the search
chain defined in environment variable "boot_targets", until boot
succeeds from some device. This can happen automatically as part of
the default boot process on some boards (example: Rock Pi 4) depending
on the board configuration (DISTRO_DEFAULTS, BOOTSTD, BOOTCOMMAND,
etc.) because they have bootcmd=bootflow scan.

If boot doesn't succeed from any device, and usb is in boot_targets,
and an usb storage device is plugged to some usb port at boot time,
its UCLASS_MASS_STORAGE device will have a UCLASS_BOOTDEV device as
child, besides a UCLASS_BLK child.

If once the boot fails the user enters at the U-Boot shell prompt:

usb info

or

usb tree

The code in cmd/usb.c will eventually recurse into the UCLASS_BOOTDEV
device and pass a null usb_device pointer to usb_show_tree_graph() or
usb_show_info() (because it has no parent_priv_).

This causes a reset. The expected behaviour would be to ignore the
UCLASS_BOOTDEV device, continue listing the usb information and return
to the prompt.


Minimal test:

Another way to trigger this reset as a minimal test or on boards with
a different bootcmd would be:

- make sure "usb" is in environment variable boot_targets (might need
   setenv boot_targets usb; and/or saveenv and reset), then, with a usb
   storage device plugged to a usb port, run:

=> usb reset ; bootflow scan ; usb info


Solution:

Fix it (twice) by checking for null parent_priv_ and adding
UCLASS_BOOTDEV to the list of ignored class ids before the recursive
call.

This prevents the current particular problem with UCLASS_BOOTDEV, even
in case it ever gets some parent_priv_ struct which is not an
usb_device, despite being the child of a usb_device->dev. And it also
prevents possible future problems if other children are added to usb
devices that don't have parent_priv_ because they are not part of the
usb tree, just abstractions of functionality (like UCLASS_BLK and
UCLASS_BOOTDEV are now).


Signed-off-by: Xavier Drudis Ferran 
Reviewed-by: Simon Glass 
Reviewed-by: Marek Vasut 
Tested-by: Marek Vasut 

---

v2: added UCLASS_BOOTDEV check (discussion of v1 dried up without much
 evident consensus, so hopefully Simon Glass likes it better now)
 [ 
https://patchwork.ozlabs.org/project/uboot/patch/zh39sva1vbzr3...@xdrudis.tinet.cat/
 ]
 Improved the commit message trying to follow Marek Vasut's advice.
 
---

  cmd/usb.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index 6193728384..23253f2223 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -421,7 +421,9 @@ static void usb_show_tree_graph(struct usb_device *dev, 
char *pre)
 * Ignore emulators and block child devices, we only want
 * real devices
 */
-   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+   if (udev &&
+   (device_get_uclass_id(child) != UCLASS_BOOTDEV) &&
+   (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
(device_get_uclass_id(child) != UCLASS_BLK)) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
@@ -604,10 +606,12 @@ static void usb_show_info(struct usb_device *udev)
 child;
 device_find_next_child(&child)) {
if (device_active(child) &&
+   (device_get_uclass_id(child) != UCLASS_BOOTDEV) &&
(device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
(device_get_uclass_id(child) != UCLASS_BLK)) {
udev = dev_get_parent_priv(child);
-   usb_show_info(udev);
+   if (udev)
+   usb_show_info(udev);
}
}
  }



Applied to usb/master, thanks.

Re: [PATCH v3 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register


On 6/21/23 05:13, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

This bug was found during the testing on Simics model. Referring to
specification DesignWare Cores USB 2.0 Hi-Speed On-The-Go (OTG)
Databook (3.30a)"5.3.4.8 Host Port Control and Status Register (HPRT)", the
HPRT.PrtPwr is cleared by this mistake. In the Linux driver (contrary to
U-Boot), HPRT is always read using dwc2_read_hprt0 helper function which
clears W1C bits. So after write back those bits are zeroes.

Signed-off-by: Teik Heng Chong 

---

V2->V3
- update commit message
---
  drivers/usb/host/dwc2.c | 34 --
  drivers/usb/host/dwc2.h |  4 
  2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
  
  	/* Turn on the vbus power. */

if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(®s->hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, ®s->hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
  
  		case USB_PORT_FEAT_RESET:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_POWER:

-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_ENABLE:

@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
  
-	clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |

-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
  
  	for (i = 0; i < MAX_DEVICE; i++) {

for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
  static void dwc2_uninit_common(struct dwc2_core_regs *regs)
  {
/* Put everything in reset. */
-   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
  }
  
  #if !CONFIG_IS_ENABLED(DM_USB)

diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
  #define DWC2_HPRT0_PRTSPD_LOW

[PATCH V2 2/2] common: splash_source: Fix type casting errors

During compilation splash_source puts out below warning for type
conversion in splash_load_fit for bmp_load_addr and fit_header.
Change their type to uintptr_t to fix the warnings.

common/splash_source.c: In function ‘splash_load_fit’:
common/splash_source.c:366:22: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  366 | img_header = (struct legacy_img_hdr *)bmp_load_addr;
  |  ^
common/splash_source.c:376:49: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  376 | res = splash_storage_read_raw(location, (u32)fit_header, 
fit_size);
  | ^
common/splash_source.c:401:25: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  401 | memmove((void *)bmp_load_addr, internal_splash_data, 
internal_splash_size);

The above warnings are generated if CONFIG_FIT is enabled.

Signed-off-by: Nikhil M Jain 
---
V2:
- Type cast bmp_load_addr to uintptr_t at places necessary instead of
  changing argument type for splash_load_fit as done in splash_load_raw.

 common/splash_source.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index a260137619..7223a1aae7 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -363,7 +363,7 @@ static int splash_load_fit(struct splash_location 
*location, u32 bmp_load_addr)
if (res < 0)
return res;
 
-   img_header = (struct legacy_img_hdr *)bmp_load_addr;
+   img_header = (struct legacy_img_hdr *)(uintptr_t)bmp_load_addr;
if (image_get_magic(img_header) != FDT_MAGIC) {
printf("Could not find FDT magic\n");
return -EINVAL;
@@ -373,7 +373,7 @@ static int splash_load_fit(struct splash_location 
*location, u32 bmp_load_addr)
 
/* Read in entire FIT */
fit_header = (const u32 *)(bmp_load_addr + header_size);
-   res = splash_storage_read_raw(location, (u32)fit_header, fit_size);
+   res = splash_storage_read_raw(location, (uintptr_t)fit_header, 
fit_size);
if (res < 0)
return res;
 
@@ -398,7 +398,7 @@ static int splash_load_fit(struct splash_location 
*location, u32 bmp_load_addr)
/* Extract the splash data from FIT */
/* 1. Test if splash is in FIT internal data. */
if (!fit_image_get_data(fit_header, node_offset, &internal_splash_data, 
&internal_splash_size))
-   memmove((void *)bmp_load_addr, internal_splash_data, 
internal_splash_size);
+   memmove((void *)(uintptr_t)bmp_load_addr, internal_splash_data, 
internal_splash_size);
/* 2. Test if splash is in FIT external data with fixed position. */
else if (!fit_image_get_data_position(fit_header, node_offset, 
&external_splash_addr))
is_splash_external = true;
-- 
2.34.1

[PATCH V2 1/2] board: ti: am62x: evm: Include necessary header files

At the time of compilation evm.c gives below warning for implicit
declaration of enable_caches, to mitigate this include cpu_func.h.

board/ti/am62x/evm.c: In function ‘spl_board_init’:
board/ti/am62x/evm.c:90:9: warning: implicit declaration of function 
‘enable_caches’ [-Wimplicit-function-declaration]
90 | enable_caches();

Signed-off-by: Nikhil M Jain 
---
V2:
- No change.

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

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index d3c1786cd9..ad93908840 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.34.1

[PATCH V2 0/2] Fix warnings occurred during compilation

This patch series aims at fixing warnings which occur during
compilation, by including required header files and using appropriate
types for variables which are typecasted.

Changes in V2:
- Type cast bmp_load_addr to uintptr_t at places necessary rather than
  changing argument type.

Nikhil M Jain (2):
  board: ti: am62x: evm: Include necessary header files
  common: splash_source: Fix type casting errors.

 board/ti/am62x/evm.c   | 1 +
 common/splash_source.c | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.34.1

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-21 Thread Andre Przywara

On Tue, 20 Jun 2023 16:11:48 -0600
Sam Edwards  wrote:

Hi Sam,

pleasure to write with you ;-)

> On 6/20/23 06:42, Andre Przywara wrote:
> > So yeah, the request of a "Enter FEL" command came up multiple times, but
> > so far no one could be bothered to implement this properly. The idea would
> > be to have a generic command (more like "fel-reset" than efex), and
> > allow each SoC (family) to implement this differently, as every
> > SoC requires something a bit different here (32-bit vs. 64-bit, having an
> > RTC vs not, etc).
> > 
> > If you could post your solution somewhere, we could start this effort.
> > There was some patch for the H3 already, and it's relatively
> > straight-forward on the newer SoCs (H616, IIRC), so if at least two
> > popular, but different SoCs would be supported, we could make sure to have
> > the right abstractions in place.  
> 
> I already have a "go_to_fel()" that does the right thing to enter FEL 
> from the SPL; I would pretty much just need to introduce the following 
> per-SoC(-family) functions:
> - bool sunxi_fel_flag_test(void)
> - void sunxi_fel_flag_clear(void)
> - void sunxi_fel_flag_set(void)

Well, so this is actually the fallback implementation which should
somewhat work on most SoCs: set a flag, reset, and catch the flag in
the SPL. For modern SoCs with CPU hotplug support (the H616 is one one
of those, and it looks like the T113s is as well), there is actually a more
direct route:
We put some magic and the FEL entry address into some special memory
locations, then just reset. Now the *BootROM* will do the check already,
and branch to the provided entry point, which would be the FEL routine.
This doesn't rely on a prepared SPL to be loaded, so works without a
boot device with mainline U-Boot around.
Refer to section 3.4.2.3 and 3.4.2.4 of the T113-S3 user manual (v1.1).
According to this, the magic would be 0xfa50392f, the magic's address is
0x070005C0, and CPU0's entry point address would be in 0x070005C4. I had a
proof of concept implementation for the H616 using this method. The only
problem left would be that someone needs to clean the magic afterwards,
otherwise any follow-up reset would trigger FEL mode again.

> The "fel-reset" command (which is easier to type than what I have, "run 
> fel_do_enter") would then call sunxi_fel_flag_set() and initiate a 
> reset, and the SPL's early init just has to do sunxi_fel_flag_test() -> 
> sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough.
> 
> Could you recommend to me a sufficiently different chip to test my 
> abstractions against? Something ARMv8 and *without* RTC?

I think all ARMv8 parts have an RTC, so your generic approach might work
there as well. The complication is that the SPL switches to AArch64 very
early, in hand-stitched AArch32 assembly, check out
arch/arm/include/asm/arch-sunxi/boot0.h.
The check would need to be coded like this, then.

> I can then send 
> in a series adding FEL support for that. (Also, did that H3 patch 
> actually land? I didn't see anything but want to know if I should be 
> refactoring my approach to extend what that H3 patch does or not.)

https://patchwork.ozlabs.org/project/uboot/patch/c211aa414c59e7275fef82bf6f0035276d6e29f3.1656875482.git.msucha...@suse.de/

Another generic approach for ARMv7 parts would be to reset the peripherals
as much as possible, then configure the core in a BROM compatible way
(MMU off, etc) and just branch to the BROM FEL entry address. This idea is
already somewhat used in our return-to-FEL code in the SPL, although we
don't change too much of the core setup in the SPL.

> > Ah, depending on the BSP kernel is indeed quite bad. I wonder what
> > features of the kernel you rely on that upstream does not have? Or is it
> > more about the BMC userland parts that are married to the Allwinner kernel
> > and its own interfaces?  
> 
> I don't fully know; getting the kernel back on mainline is, as I said, a 
> push for another day. I'm very much making a point of not looking into 
> it before the bootloader can be upgraded to something that isn't a 
> crashy, hard-to-update, failure-prone mess. (I'm working in "biggest 
> fire, first out" order.)

Fair enough, from a mainlining point of view you need to funnel the
board .dts through the Linux tree first, though.
Also, with the right DT, a mainline kernel would run on the board
already, maybe just not with the full functionality you'd expect from
it.

What I mean to say: you can surely continue using Tina Linux for the
BMC functionality on the board right now, but still upstream the board
.dts. As mentioned, the DT just describes the hardware, so it doesn't
dictate what to do with it. One might abuse the board as a T113s dev
board, maybe ;-) Does it work without any of the modules populated?

> That said, the first such dependent feature that leaps to mind is the 
> AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically 
> interleaves pages of the NAND in a different ordering vs.

[PATCH V5 8/9] configs: am62x_evm_a53: Add bloblist address

Set bloblist address to 0x80D0.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
V5:
- No change.

V4:
- Remove the link to SPL DDR memory layout and add a new patch.

V3:
- Add link to updated memory map.

V2:
- Add Reviewed-by tag.

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

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 7c3bc184cf..5c572dfb33 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -102,3 +102,4 @@ CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_BLOBLIST_ADDR=0x80D0
-- 
2.34.1

[PATCH V5 9/9] doc: board: ti: am62x_sk: Add A53 SPL DDR layout

To understand usage of DDR in A53 SPL stage, add a table showing region
and space used by major components of SPL.

Signed-off-by: Nikhil M Jain 
---
V5:
- Change the layout of A53 SPL DDR into tabular format.

V4(patch introduced):
- Document A53 SPL DDR memory layout.

 doc/board/ti/am62x_sk.rst | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index 27d7b527c6..8642bdf16d 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -230,6 +230,63 @@ Image formats:
 | +---+ |
 +---+
 
+A53 SPL DDR Memory Layout
+-
+
+This provides an overview memory usage in A53 SPL stage.
+
+.. list-table::
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Region
+ - Start Address
+ - End Address
+
+   * - EMPTY
+ - 0x8000
+ - 0x8008
+
+   * - TEXT BASE
+ - 0x8008
+ - 0x800d8000
+
+   * - EMPTY
+ - 0x800d8000
+ - 0x8020
+
+   * - BMP IMAGE
+ - 0x8020
+ - 0x80b77660
+
+   * - STACK
+ - 0x80b77660
+ - 0x80b77e60
+
+   * - GD
+ - 0x80b77e60
+ - 0x80b78000
+
+   * - MALLOC
+ - 0x80b78000
+ - 0x80b8
+
+   * - EMPTY
+ - 0x80b8
+ - 0x80c8
+
+   * - BSS
+ - 0x80c8
+ - 0x80d0
+
+   * - BLOBS
+ - 0x80d0
+ - 0x80d00400
+
+   * - EMPTY
+ - 0x80d00400
+ - 0x8100
+
 Switch Setting for Boot Mode
 
 
-- 
2.34.1

[PATCH V5 6/9] drivers: video: Kconfig: Add config remove video

This is required since user may want to either call the remove method
of video driver and reset the display or not call the remove method
to continue displaying until next stage.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
Reviewed-by: Tom Rini 
---
V5:
- No change.

V4:
- Add Reviewed-by tag.

V3:
- No change.

V2:
- Add Reviewed-by tag.

 drivers/video/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4976295071..de64e33c2f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -833,6 +833,12 @@ config IHS_VIDEO_OUT
  out On-screen Display (OSD) used on gdsys FPGAs to control dynamic
  textual overlays of the display outputs.
 
+config VIDEO_REMOVE
+   bool "Remove video driver"
+   help
+ Use this option to specify if user wants to call remove method of
+ video driver in u-boot proper stage.
+
 config SPLASH_SCREEN
bool "Show a splash-screen image"
help
@@ -1056,6 +1062,12 @@ config SPL_SYS_WHITE_ON_BLACK
 This can be better in low-light situations or to reduce eye strain in
 some cases.
 
+config SPL_VIDEO_REMOVE
+   bool "Remove video driver after SPL stage"
+   help
+ if this  option is enabled video driver will be removed at the end of
+ SPL stage, beforeloading the next stage.
+
 if SPL_SPLASH_SCREEN
 
 config SPL_SPLASH_SCREEN_ALIGN
-- 
2.34.1

[PATCH V5 7/9] common: spl: spl: Remove video driver

Use config SPL_VIDEO_REMOVE to remove video driver at SPL stage before
jumping to next stage, in place of CONFIG_SPL_VIDEO, to allow user to
remove video if required.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
V5:
- No change.

V4:
- No change.

V3:
- Replace #if defined(CONFIG_SPL_VIDEO_REMOVE) with
  if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE).

V2:
- Add Reviewed-by tag.

 common/spl/spl.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index d45dd1c923..f09bb97781 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -891,18 +891,18 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
debug("Failed to stash bootstage: err=%d\n", ret);
 #endif
 
-#if defined(CONFIG_SPL_VIDEO)
-   struct udevice *dev;
-   int rc;
-
-   rc = uclass_find_device(UCLASS_VIDEO, 0, &dev);
-   if (!rc && dev) {
-   rc = device_remove(dev, DM_REMOVE_NORMAL);
-   if (rc)
-   printf("Cannot remove video device '%s' (err=%d)\n",
-  dev->name, rc);
+   if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE)) {
+   struct udevice *dev;
+   int rc;
+
+   rc = uclass_find_device(UCLASS_VIDEO, 0, &dev);
+   if (!rc && dev) {
+   rc = device_remove(dev, DM_REMOVE_NORMAL);
+   if (rc)
+   printf("Cannot remove video device '%s' 
(err=%d)\n",
+  dev->name, rc);
+   }
}
-#endif
 
spl_board_prepare_for_boot();
jump_to_image_no_args(&spl_image);
-- 
2.34.1

[PATCH V5 5/9] common: board_f: Pass frame buffer info from SPL to u-boot

U-boot proper can use frame buffer address passed from SPL to reserve
the memory area used by framebuffer set in SPL so that splash image
set in SPL continues to get displayed while u-boot proper is running.

Put the framebuffer address and size in a bloblist to make them
available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V5:
- No change.

V4:
- Add Reviewed-by tag.

V3:
- Clean up errors appeared in checkpatch.

V2:
- Fix commit message.
- Revert use of #if.

 common/board_f.c | 11 ++-
 drivers/video/video-uclass.c | 12 
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 1688e27071..8e5dbaf06c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -411,7 +411,16 @@ __weak int arch_reserve_mmu(void)
 
 static int reserve_video(void)
 {
-   if (IS_ENABLED(CONFIG_VIDEO)) {
+   if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL &&
+   CONFIG_IS_ENABLED(BLOBLIST)) {
+   struct video_handoff *ho;
+
+   ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
+   if (!ho)
+   return log_msg_ret("blf", -ENOENT);
+   video_reserve_from_bloblist(ho);
+   gd->relocaddr = ho->fb;
+   } else if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
 
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 497ebd9acf..1a318e2310 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -6,12 +6,14 @@
 #define LOG_CATEGORY UCLASS_VIDEO
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -139,6 +141,16 @@ int video_reserve(ulong *addrp)
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
  gd->video_top);
 
+   if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+   struct video_handoff *ho;
+
+   ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+   if (!ho)
+   return log_msg_ret("blf", -ENOENT);
+   ho->fb = *addrp;
+   ho->size = size;
+   }
+
return 0;
 }
 
-- 
2.34.1

[PATCH V5 4/9] include: video: Reserve video using blob

Add method to reserve video framebuffer information using blob,
received from previous stage.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Simon Glass 
---
V5:
- No change.

V4:
- No change.

V3:
- Add Reviewed-by tag.

V2:
- Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob.

 drivers/video/video-uclass.c | 11 +++
 include/video.h  |  9 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 1b66a8061a..497ebd9acf 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -142,6 +142,17 @@ int video_reserve(ulong *addrp)
return 0;
 }
 
+int video_reserve_from_bloblist(struct video_handoff *ho)
+{
+   gd->video_bottom = ho->fb;
+   gd->fb_base = ho->fb;
+   gd->video_top = ho->fb + ho->size;
+   debug("Reserving %luk for video using blob at: %08x\n",
+ ((unsigned long)ho->size) >> 10, (u32)ho->fb);
+
+   return 0;
+}
+
 int video_fill(struct udevice *dev, u32 colour)
 {
struct video_priv *priv = dev_get_uclass_priv(dev);
diff --git a/include/video.h b/include/video.h
index fffaae84e5..bdf1cf7855 100644
--- a/include/video.h
+++ b/include/video.h
@@ -390,4 +390,13 @@ int bmp_display(ulong addr, int x, int y);
  */
 int bmp_info(ulong addr);
 
+/*
+ * video_reserve_from_bloblist()- Reserve frame-buffer memory for video devices
+ * using blobs.
+ *
+ * @ho: video information passed from SPL
+ * Returns: 0 (always)
+ */
+int video_reserve_from_bloblist(struct video_handoff *ho);
+
 #endif
-- 
2.34.1

[PATCH V5 3/9] board: ti: am62x: evm: Update function calls for splash screen

Use spl_dcache_enable, in place of setup_dram, arch_reserve_mmu to set
up pagetable, initialise DRAM and enable Dcache to avoid multiple
function calls.

Check for CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to prevent
any build failure in case video config is not defined and video related
functions are called.

Check for CONFIG_SPL_SPLASH_SCREEN and CONFIG_SPL_BMP before calling
splash_display to avoid compilation failure.

Signed-off-by: Nikhil M Jain 
---
V5:
- No change.

V4:
- Update commit message as per comments.

V3:
- No change.

V2:
- Use CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to reserve
  video and  call splash at SPL.
- Check SPL_SPLASH_SCREEN and SPL_BMP before calling splash display.

 arch/arm/mach-k3/am625_init.c |  1 +
 board/ti/am62x/evm.c  | 41 +--
 2 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 787fe92295..0e5d44269e 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -214,6 +214,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
 #endif
+   spl_enable_dcache();
 }
 
 u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 34830f445f..d3c1786cd9 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -59,42 +59,31 @@ int dram_init_banksize(void)
 }
 
 #if defined(CONFIG_SPL_BUILD)
-#ifdef CONFIG_SPL_VIDEO_TIDSS
-static int setup_dram(void)
-{
-   dram_init();
-   dram_init_banksize();
-   gd->ram_base = CFG_SYS_SDRAM_BASE;
-   gd->ram_top = gd->ram_base + gd->ram_size;
-   gd->relocaddr = gd->ram_top;
-   return 0;
-}
-
 static int video_setup(void)
 {
-   ulong addr;
-   int ret;
-   addr = gd->relocaddr;
+   if (CONFIG_IS_ENABLED(VIDEO)) {
+   ulong addr;
+   int ret;
+
+   addr = gd->relocaddr;
+   ret = video_reserve(&addr);
+   if (ret)
+   return ret;
+   debug("Reserving %luk for video at: %08lx\n",
+ ((unsigned long)gd->relocaddr - addr) >> 10, addr);
+   gd->relocaddr = addr;
+   }
 
-   ret = video_reserve(&addr);
-   if (ret)
-   return ret;
-   debug("Reserving %luk for video at: %08lx\n",
- ((unsigned long)gd->relocaddr - addr) >> 10, addr);
-   gd->relocaddr = addr;
return 0;
 }
 
-#endif
 void spl_board_init(void)
 {
-#if defined(CONFIG_SPL_VIDEO_TIDSS)
-   setup_dram();
-   arch_reserve_mmu();
video_setup();
enable_caches();
-   splash_display();
-#endif
+   if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
+   splash_display();
+
 }
 
 #if defined(CONFIG_K3_AM64_DDRSS)
-- 
2.34.1

[PATCH V5 2/9] arch: arm: mach-k3: common: Return a pointer after setting page table

In spl_dcache_enable after setting up page table, set gd->relocaddr
pointer to tlb_addr, to get next location to reserve memory. Align
tlb_addr with 64KB address.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
V5:
- No change.

V4:
- Add Reviewed-by tag.

V3:
- No change.

V2:
- Perform 64KB alignment on tlb_addr.

 arch/arm/mach-k3/common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index bda01527d3..f9cfa66059 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -629,8 +629,10 @@ void spl_enable_dcache(void)
ram_top = (phys_addr_t) 0x1;
 
gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+   gd->arch.tlb_addr &= ~(0x1 - 1);
debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
  gd->arch.tlb_addr + gd->arch.tlb_size);
+   gd->relocaddr = gd->arch.tlb_addr;
 
dcache_enable();
 #endif
-- 
2.34.1

[PATCH V5 1/9] common: spl: spl: Update stack pointer address

At SPL stage when stack is relocated, the stack pointer needs to be
updated, the stack pointer may point to stack in on chip memory even
though stack is relocated.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Tom Rini 
---
V5:
- No change.

V4:
- No change.

V3:
- Add Reviewed-by tag.

V2:
- No change.

 common/spl/spl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index d74acec10b..d45dd1c923 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -992,6 +992,7 @@ ulong spl_relocate_stack_gd(void)
 #endif
/* Get stack position: use 8-byte alignment for ABI compliance */
ptr = CONFIG_SPL_STACK_R_ADDR - roundup(sizeof(gd_t),16);
+   gd->start_addr_sp = ptr;
new_gd = (gd_t *)ptr;
memcpy(new_gd, (void *)gd, sizeof(gd_t));
 #if CONFIG_IS_ENABLED(DM)
-- 
2.34.1

[PATCH V5 0/9] Update SPL splashscreen framework for AM62x

This patch series aims at updating SPL splashscreen framework for AM62x.

This patch series depends on
https://lore.kernel.org/u-boot/20230504225829.2537050-1-...@chromium.org/

This series:
- Fixes compilation issues in case splash related configs are not
  defined in SPL.
- Does page table setup, dram initialisation and dcache enabling in
  one function call spl_enable_dcache.
- Allows passing of framebuffer from spl to u-boot, eliminating flicker.

V5:
- Change A53 SPL DDR layout from ASCII table to tabular format.

V4:
- Fix commit message.
- Introduce patch defining DDR layout in A53 SPL.
- Add Reviewed-by tags.

V3:
- Fix spacing issues.
- Add Reviewed-by tag.
- Replace #if with if in patch
  common: spl: spl: Remove video driver
- Add link to updated memory map.

V2:
- Update cover letter.
- Fix commit message.

Nikhil M Jain (9):
  common: spl: spl: Update stack pointer address
  arch: arm: mach-k3: common: Return a pointer after setting page table
  board: ti: am62x: evm: Update function calls for splash screen
  include: video: Reserve video using blob
  common: board_f: Pass frame buffer info from SPL to u-boot
  drivers: video: Kconfig: Add config remove video
  common: spl: spl: Remove video driver
  configs: am62x_evm_a53: Add bloblist address
  doc: board: ti: am62x_sk: Add A53 SPL DDR layout

 arch/arm/mach-k3/am625_init.c   |  1 +
 arch/arm/mach-k3/common.c   |  2 ++
 board/ti/am62x/evm.c| 41 +---
 common/board_f.c| 11 ++-
 common/spl/spl.c| 23 ++---
 configs/am62x_evm_a53_defconfig |  1 +
 doc/board/ti/am62x_sk.rst   | 57 +
 drivers/video/Kconfig   | 12 +++
 drivers/video/video-uclass.c| 23 +
 include/video.h |  9 ++
 10 files changed, 142 insertions(+), 38 deletions(-)

-- 
2.34.1

RE: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-21 Thread Jose Marinho

Hi,

> -Original Message-
> From: Michal Simek 
> Sent: Tuesday, June 20, 2023 3:20 PM
> To: Jassi Brar ; Ilias Apalodimas
> 
> Cc: Jose Marinho ; u-boot@lists.denx.de;
> etienne.carri...@linaro.org; tr...@konsulko.com; s...@chromium.org;
> sughosh.g...@linaro.org; xypron.g...@gmx.de; takahiro.aka...@linaro.org
> Subject: Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on
> DeveloperBox
> 
> 
> 
> On 6/20/23 16:14, Jassi Brar wrote:
> > On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas
> >  wrote:
> >>
> >> Sorry for being late to the party,
> >>
> >> +cc Jose who maintains DEN0118
> >>
> >> On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:
> >>> Hi Michal,
> >>>
> >>> On Mon, 19 Jun 2023 at 10:02, Michal Simek 
> wrote:
> 
>  Hi Jassi,
> 
>  On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:
> > From: Jassi Brar 
> >
> > Introduce support for mtd backed storage for FWU feature and
> > enable it on Synquacer platform based DeveloperBox.
> >
> > This revision is rebased onto patchset that trims the FWU api
> >
> > https://lore.kernel.org/u-boot/20230306231747.1888513-1-
> jassisingh
> > b...@gmail.com/
> >
> >>> .
> >>>
>  Firstly I can generate 2 images per one bank which should be pretty
>  much regular capsule update for 2 images. I would expect this should 
>  still
> work.
> 
>  And then I tried 2 banks with 2 images and
>  fwu_gen_alt_info_from_mtd() generated this description for DFU
> 
>  mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd
>  nor0=bank0 raw
>  23a 400;bank1 raw 282 400
> 
>  If you look at size in second entry you will see that it is 8000
>  instead of
>  8 because it is the same image. That's why curious if you have
>  tested any scenario like this.
> 
> >>> I had, and have, strong doubts about the practicality of 2
> >>> images/bank. There aren't enough specification details to explain
> >>> how only 1-out-of-N images could be updated. And if we always update
> >>> all images in a bank together, we might as well have them as one
> >>> composite image. I never got satisfactory clarification from
> >>> designers and implementers. So, sorry, I can't defend that scenario
> >>> with my limited knowledge.
> >>
> >> This is intentionally left out, as we consider it a platform policy.
> >> For example you could update a single bank and copy over the
> >> remaining firmware images from a different ban. There's nothing on
> >> the spec that prohibits you from doing so, but I personally think it's a 
> >> bad
> idea.
> >>
> > Me too.
> >
> >> Keep in mind there's a document hosted here[0] which explains the
> >> update flow and documents what we have as code in U-Boot.
> >>
> >> As far as individual firmware components go now,  do you have any
> >> useful usecase?
> >>
> > No.  And I don't think current A/B update implementation in u-boot
> > even has helpers for platforms to implement multiple images per bank.
> > Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK
> > config -- which will always be set to 1 I predict ;)
> 
> Actually support is there but it requires one thing to patch. I will send that
> patch when I clean my repo.
> And I have tested it on our platform.
> 
> >
> >>   The general guidance of [0] is construct a firmware image, only
> >> update the components you want while leaving the rest on the same
> >> revisions and update the entire firmware.  The reason is that
> >> firmware
> >>
> >> Updating a single image of another bank is not as easy as it sounds.
> >>
> > exactly.
> >
> >> Firmware components nowadays, whether we like it or not, depend on
> each other.
> >> Since firmware updates are not so often and fast,  we didn't see any
> >> gains from over complicating the spec and explicitly describe that
> >> case, while dealing with firmware component compatibility at the same
> time.
> >>
> > Totally.  As I said, I don't believe in the practicality of more than
> > 1 image/bank.
> > So we are on the same page.
> >
> >>>
>  Next part which I want to take a look is practicality of
>  CONFIG_FWU_NUM_BANKS and
> CONFIG_FWU_NUM_IMAGES_PER_BANK because it
>  pretty much enforcing number of banks and images for every platform
>  and prevent creating one u-boot which works on different boards and
> just use information from mdata.
>  DEN0118 doesn't show any field with this information but do you
>  think that would be possible to extract that information from there
>  based on for example reserved or accepted field?
> 
> >>> Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits
> >>> in 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If
> >>> we use any bit, we'll be in violation of the spec.
> >>
> >> Yes this is unfortunate.  We did have similar concerns on when
> >> drafting the spec,  however we never had a solid usecase

[PATCH v1 3/4] net: rtl8169: Add one more device ID

Add the NIC device ID and adjust the PCI bar regions.

Signed-off-by: Minda Chen 
---
 drivers/net/rtl8169.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 34e4cff1e9..963702777c 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -353,10 +353,11 @@ static const unsigned int rtl8169_rx_config =
 (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift);
 
 static struct pci_device_id supported[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8125) },
+   { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8161) },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167) },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168) },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169) },
-   { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8125) },
{}
 };
 
@@ -1051,8 +1052,9 @@ static int rtl8169_eth_probe(struct udevice *dev)
int ret;
 
switch (pplat->device) {
-   case 0x8168:
case 0x8125:
+   case 0x8161:
+   case 0x8168:
region = 2;
break;
default:
-- 
2.17.1

[PATCH v1 4/4] configs: starfive-jh7110: Add CONFIG_RTL8169

Add PCIe device rtl8169 net adapter driver support.

Signed-off-by: Minda Chen 
---
 configs/starfive_visionfive2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/starfive_visionfive2_defconfig 
b/configs/starfive_visionfive2_defconfig
index ffbc4b9476..360160200f 100644
--- a/configs/starfive_visionfive2_defconfig
+++ b/configs/starfive_visionfive2_defconfig
@@ -66,6 +66,7 @@ CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_RTL8169=y
 CONFIG_PINCTRL=y
 CONFIG_PINCONF=y
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1

[PATCH v1 2/4] net: rtl8169: Fix DMA min aligned compile warning in riscv

Fix rtl8169 descriptor less the DMA min aligned compile warning
for RISC-V SoC platform.

Signed-off-by: Minda Chen 
---
 drivers/net/rtl8169.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index dcba51590d..34e4cff1e9 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -311,10 +311,12 @@ static unsigned char rxdata[RX_BUF_LEN];
  *
  * This can be fixed by defining CONFIG_SYS_NONCACHED_MEMORY which will cause
  * the driver to allocate descriptors from a pool of non-cached memory.
+ *
+ * Hardware maintain D-cache coherency in RISC-V architecture.
  */
 #if RTL8169_DESC_SIZE < ARCH_DMA_MINALIGN
 #if !defined(CONFIG_SYS_NONCACHED_MEMORY) && \
-   !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) && !defined(CONFIG_X86)
+   !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) && !defined(CONFIG_X86) && 
!defined(CONFIG_RISCV)
 #warning cache-line size is larger than descriptor size
 #endif
 #endif
-- 
2.17.1

[PATCH v1 0/4] Fix rtl8169 compile warning and add a new device ID

StarFive JH7110 uboot support PCIe and using rtl8169 network adapter
PCIe device. But compile warning in rtl8169 driver cause CI test fail.
So commit this patch set to fix it, Also a new device ID to adjust the
PCI bar regions in rtl8169.

The StarFive JH7110 PCIe driver link:
https://patchwork.ozlabs.org/project/uboot/cover/20230509082617.119018-1-minda.c...@starfivetech.com/

patch 1 is fix make pointer from integer warning.
 eg: /home/minda/vf2/visionfive/u-boot/drivers/net/rtl8169.c:103:52: warning:
passing argument 2 of ‘writew’ makes pointer from integer without a cast 
[-Wint-conversion]
patch 2 fix RISC-V 8169 descriptor less than DMA min aligned size warning
patch 3 add new device ID
patch 4 enable 8169 in JH7110 SoC configs file.

Minda Chen (4):
  net: rtl8169: Fix compile warning in rtl8169 network adapter
  net: rtl8169: Fix DMA min aligned compile warning in riscv
  net: rtl8169: Add one more device ID
  configs: starfive-jh7110: Add CONFIG_RTL8169

 configs/starfive_visionfive2_defconfig |  1 +
 drivers/net/rtl8169.c  | 22 +-
 2 files changed, 14 insertions(+), 9 deletions(-)


base-commit: 50842b217fef505a0ec6662cc2acdc55d0bb23c5
-- 
2.17.1

[PATCH v1 1/4] net: rtl8169: Fix compile warning in rtl8169 network adapter