Re: [PATCH 23/40] lmb: add a flags parameter to the API's

[Sughosh Ganu]

On Thu, 8 Aug 2024 at 19:58, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Wed, 7 Aug 2024 at 00:32, Sughosh Ganu  wrote:
> >
> > On Wed, 7 Aug 2024 at 03:21, Simon Glass  wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Mon, 5 Aug 2024 at 05:55, Sughosh Ganu  wrote:
> > > >
> > > > On Mon, 29 Jul 2024 at 20:56, Simon Glass  wrote:
> > > > >
> > > > > Hi Sughosh,
> > > > >
> > > > > On Mon, 29 Jul 2024 at 02:40, Sughosh Ganu  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, 26 Jul 2024 at 05:02, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Sughosh,
> > > > > > >
> > > > > > > On Wed, 24 Jul 2024 at 00:04, Sughosh Ganu 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Add a flags parameter to the LMB API functions. The parameter 
> > > > > > > > can then
> > > > > > > > be used to pass any other type of reservations or allocations 
> > > > > > > > needed
> > > > > > > > by the callers. These will be used in a subsequent set of 
> > > > > > > > changes for
> > > > > > > > allocation requests coming from the EFI subsystem.
> > > > > > > >
> > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > ---
> > > > > > > > Changes since rfc: New patch
> > > > > > > >
> > > > > > > >  arch/arm/mach-apple/board.c   |  17 ++--
> > > > > > > >  arch/arm/mach-snapdragon/board.c  |   2 +-
> > > > > > > >  arch/arm/mach-stm32mp/dram_init.c |   4 +-
> > > > > > > >  arch/powerpc/cpu/mpc85xx/mp.c |   2 +-
> > > > > > > >  arch/powerpc/lib/bootm.c  |   2 +-
> > > > > > > >  board/xilinx/common/board.c   |   4 +-
> > > > > > > >  boot/bootm.c  |   5 +-
> > > > > > > >  boot/image-board.c|  15 ++-
> > > > > > > >  boot/image-fdt.c  |  15 +--
> > > > > > > >  cmd/booti.c   |   2 +-
> > > > > > > >  cmd/bootz.c   |   2 +-
> > > > > > > >  cmd/load.c|   4 +-
> > > > > > > >  drivers/iommu/apple_dart.c|   6 +-
> > > > > > > >  drivers/iommu/sandbox_iommu.c |   6 +-
> > > > > > > >  fs/fs.c   |   2 +-
> > > > > > > >  include/lmb.h |  23 ++---
> > > > > > > >  lib/lmb.c |  48 --
> > > > > > > >  test/lib/lmb.c| 150 
> > > > > > > > +++---
> > > > > > > >  18 files changed, 150 insertions(+), 159 deletions(-)
> > > > > > >
> > > > > > > This negates any code-size advantage of dropping the lmb 
> > > > > > > parameter.
> > > > > > >
> > > > > > > All of these are LMB_NONE. Can we have a separate function (e.g.
> > > > > > > lmb_alloc_type()) for when we actually need to specify the type?
> > > > > >
> > > > > > We will be passing different values when we call the LMB API's from
> > > > > > the EFI allocation function. This is only adding a parameter to the
> > > > > > allocation API's, which I believe is better than adding separate
> > > > > > functions which take a flag parameter only to be called from the EFI
> > > > > > subsystem.
> > > > >
> > > > > No i believe it is worse, unless there are a lot of such functions.
> > > > > The flags are a special case, not the common case.
> > > >
> > > > I have done some size impact tests on the two scenarios, one where we
> > > > have a common set of lmb allocation API functions, with an added flags
> > > > parameter, and second where we have separate API's to be called from
> > > > the EFI memory module. I have put out the results of the size impact
> > > > [1].
> > > >
> > > > You will see that with common API's, we are not losing much even on
> > > > boards with EFI_LOADER disabled. But otoh, on boards which have
> > > > EFI_LOADER enabled, the gains are pretty significant. I believe we
> > > > should reconsider using a common LMB API with the flags parameter.
> > >
> > > Thanks for looking at it.
> > >
> > > Did you do special versions of just lmb_alloc() and lmb_add() which
> > > call the flags versions? It seems that there is no size advantage with
> > > EFI_LOADER and only a small one with !EFI_LOADER. Can you please point
> > > me to the code?
> >
> > For the separate API version, I introduced new versions
> > lmb_alloc_flags(), lmb_alloc_base_flags(), lmb_alloc_addr_flags() and
> > lmb_free_flags(), which are being called from the EFI memory module. I
> > have pushed the two branches [1] [2] on my github. Please take a look.
> >
> > Btw, both these branches are based on your v5 of the alist patches,
> > and also incorporate the stack based implementation for running the
> > lmb tests. So except for either having common API's, or not, there are
> > no other differences between the two. Thanks.
>
> Thanks for the info.
>
> The non-flags functions can call the flags functions, so that you
> don't create a new code path. Something like this:
>
> diff --git a/lib/lmb.c b/lib/lmb.c
> index 726e6c38227..0a251c587fe 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -528,7 +528,7 @@ long lmb_free_flags(phys_addr_t base, phy

Re: [PATCH] rockchip: configs: puma-rk3399: disable VIDEO support that breaks Linux

[Kever Yang]

On 2024/7/29 19:04, Quentin Schulz wrote:

From: Quentin Schulz 

RK3399 Puma has support for driving multiple displays at the same time,
the most notable scenario being HDMI+DSI since there exists a devkit
with both DSI display and HDMI output.

While HDMI seems to work fine in U-Boot, as the U-Boot logo is shown
whenever the EFI bootmeth is used, it messes up DSI in HDMI+DSI setup in
the Linux kernel. There are some ways to work around this bug but no
known appropriate fix for now, so let's rather not trigger this bug.

Since there isn't any client of ours that seems to be using this
feature, let's disable it for now. Users can re-enable this feature in
the event they have HDMI-only products.

Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
@linux-rockchip: you've been added to this as it's an issue in the Linux
kernel but that gets triggered from U-Boot. This is a patch for U-Boot
but I wanted it to be available in linux-rockchip archives :)

We recently ported Puma from 2022.10 to 2024.07 in our vendor tree but
discovered that this broke the DSI display on our devkit whenever an
HDMI display would be connected at boot.

While VIDEO has been enabled for a few years already on Puma, something
actually started to make use of it in the "normal" boot process (it
seems to be the EFI bootmeth?). While it seems to work okay-ish as the
U-Boot logo is shown properly, it is followed by artefacts whenever the
kernel is taking over in the boot flow. Additionally, whenever one boots
with HDMI connected and has a secondary DSI display, DSI is now broken
in the Linux kernel until I unplug HDMI.

A bit of debugging later, it seems we have a different clock for the
DCLK of the VOP used for DSI. GPLL is used whenever no HDMI is plugged
in, otherwise VPLL is used. The rate of the frac clock is also
different, with 59756KHz when it doesn't work and 59400KHz when it does.

I discovered that the frac clock doesn't try to set the rate of its
parent, the div clock, so tried the following:

"""
  diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
  index 4f1a5782c2308..fd5d11b9e12ed 100644
  --- a/drivers/clk/rockchip/clk-rk3399.c
  +++ b/drivers/clk/rockchip/clk-rk3399.c
  @@ -1166,7 +1166,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
RK3399_CLKSEL_CON(49), 8, 2, MFLAGS, 0, 8, DFLAGS,
RK3399_CLKGATE_CON(10), 12, GFLAGS),
   
  -	COMPOSITE_FRACMUX_NOGATE(DCLK_VOP0_FRAC, "dclk_vop0_frac", "dclk_vop0_div", 0,

  + COMPOSITE_FRACMUX_NOGATE(DCLK_VOP0_FRAC, "dclk_vop0_frac", 
"dclk_vop0_div", CLK_SET_RATE_PARENT,
RK3399_CLKSEL_CON(106), 0,
&rk3399_dclk_vop0_fracmux),
   
  @@ -1196,7 +1196,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {

RK3399_CLKSEL_CON(50), 8, 2, MFLAGS, 0, 8, DFLAGS,
RK3399_CLKGATE_CON(10), 13, GFLAGS),
   
  -	COMPOSITE_FRACMUX_NOGATE(DCLK_VOP1_FRAC, "dclk_vop1_frac", "dclk_vop1_div", 0,

  + COMPOSITE_FRACMUX_NOGATE(DCLK_VOP1_FRAC, "dclk_vop1_frac", 
"dclk_vop1_div", CLK_SET_RATE_PARENT,
RK3399_CLKSEL_CON(107), 0,
&rk3399_dclk_vop1_fracmux),
"""

which made it work! But... the rate of the frac (but not the div!) is
the same as well as the parent of div clock (still VPLL), so this
smelled fishy, something like a timing issue.

I therefore tried to reorder the probing of HDMI and DSI with:

"""
  diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
  index 6492f3caf0174..482b9a169653e 100644
  --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
  +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
  @@ -524,10 +524,10 @@ static int __init rockchip_drm_init(void)
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
  - ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
  - CONFIG_ROCKCHIP_DW_HDMI);
ADD_ROCKCHIP_SUB_DRIVER(dw_mipi_dsi_rockchip_driver,
CONFIG_ROCKCHIP_DW_MIPI_DSI);
  + ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
  + CONFIG_ROCKCHIP_DW_HDMI);
ADD_ROCKCHIP_SUB_DRIVER(inno_hdmi_driver, CONFIG_ROCKCHIP_INNO_HDMI);
ADD_ROCKCHIP_SUB_DRIVER(rk3066_hdmi_driver,
CONFIG_ROCKCHIP_RK3066_HDMI);
"""

this worked too!

Then, I tried something else, applying
https://lore.kernel.org/all/20240615170417.3134517-14-jo...@kwiboo.se/

... which also made it work! But re-ordering the probe order like above,
broke it again. So not perfect...

It does seem that HDMI may need to be on VOPB in multidisplay scenarios?
I honestly do not have any idea of what's going

Re: [PATCH v2 1/2] rockchip: rk3308: Remove OTP device node from soc u-boot dtsi

[Kever Yang]

On 2024/7/30 22:27, Jonas Karlman wrote:

The merged upstream DT node for OTP differs in nodename and will cause
following build errors once rk3308.dtsi in dts/upstream is updated:

   ERROR (duplicate_label): /nvmem@ff21: Duplicate label 'otp' on 
/nvmem@ff21 and /efuse@ff21
   ERROR (duplicate_label): /nvmem@ff21/id@7: Duplicate label 'cpu_id' on 
/nvmem@ff21/id@7 and /efuse@ff21/id@7

Remove the OTP device node from soc u-boot dtsi in preparation for
replacing it with the merged upstream DT node in dts/upstream.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch
---
  arch/arm/dts/rk3308-u-boot.dtsi | 16 
  1 file changed, 16 deletions(-)

diff --git a/arch/arm/dts/rk3308-u-boot.dtsi b/arch/arm/dts/rk3308-u-boot.dtsi
index 684fa7abddb1..b7964e2756f3 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -21,22 +21,6 @@
bootph-all;
};
  
-	otp: nvmem@ff21 {

-   compatible = "rockchip,rk3308-otp";
-   reg = <0x0 0xff21 0x0 0x4000>;
-   clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
-<&cru PCLK_OTP_PHY>;
-   clock-names = "otp", "apb_pclk", "phy";
-   resets = <&cru SRST_OTP_PHY>;
-   reset-names = "phy";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   cpu_id: id@7 {
-   reg = <0x07 0x10>;
-   };
-   };
-
rng: rng@ff2f {
compatible = "rockchip,cryptov2-rng";
reg = <0x0 0xff2f 0x0 0x4000>;

Re: [PATCH v2 2/2] arm64: dts: rockchip: Add OTP device node for RK3308

[Kever Yang]

On 2024/7/30 22:27, Jonas Karlman wrote:

The RK3308 SoC contains a controller for one-time-programmable memory,
add a device node for it.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-9-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 36d3bbc8cdbef2f83391f770265ac4c37a99 ]

(cherry picked from commit db11d284200d0f811a8f8238dbc9c63daf4e6131)

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch
---
  dts/upstream/src/arm64/rockchip/rk3308.dtsi | 24 +
  1 file changed, 24 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3308.dtsi
index c00da150a22f..6531ede13af9 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3308.dtsi
@@ -556,6 +556,30 @@
status = "disabled";
};
  
+	otp: efuse@ff21 {

+   compatible = "rockchip,rk3308-otp";
+   reg = <0x0 0xff21 0x0 0x4000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
+<&cru PCLK_OTP_PHY>;
+   clock-names = "otp", "apb_pclk", "phy";
+   resets = <&cru SRST_OTP_PHY>;
+   reset-names = "phy";
+
+   cpu_id: id@7 {
+   reg = <0x07 0x10>;
+   };
+
+   cpu_leakage: cpu-leakage@17 {
+   reg = <0x17 0x1>;
+   };
+
+   logic_leakage: logic-leakage@18 {
+   reg = <0x18 0x1>;
+   };
+   };
+
dmac0: dma-controller@ff2c {
compatible = "arm,pl330", "arm,primecell";
reg = <0x0 0xff2c 0x0 0x4000>;

Re: [PATCH 1/2] arm64: dts: rockchip: Add Radxa ROCK 3B

[Kever Yang]

On 2024/7/31 15:28, Jonas Karlman wrote:

The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240627211737.1985549-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 846ef7748fa9124c8eea76e2d5e833fa69b3ef7c ]

(cherry picked from commit 5416329b387d3c13392f84ba35273a402c7010f8)

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  .../src/arm64/rockchip/rk3568-rock-3b.dts | 781 ++
  1 file changed, 781 insertions(+)
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts 
b/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts
new file mode 100644
index ..3d0c1ccfaa79
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts
@@ -0,0 +1,781 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include "rk3568.dtsi"
+
+/ {
+   model = "Radxa ROCK 3B";
+   compatible = "radxa,rock-3b", "rockchip,rk3568";
+
+   aliases {
+   ethernet0 = &gmac0;
+   ethernet1 = &gmac1;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
+   mmc2 = &sdmmc2;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
+   ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwm3_ir>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led>;
+
+   led-0 {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   /* pi6c pcie clock generator */
+   vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pcie_pwren_h>;
+   regulator-name = "vcc3v3_pi6c_03";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <1>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc3v3_sys: regulator-3v3-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc3v3_sys2: regulator-3v3-vcc-sys2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys2";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc5v0_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_usb_host: regulator-5v0-vcc-usb-host {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb_host_pwren_h>;
+   regulator-name = "vcc5v0_usb_host";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc5v0_usb_otg: regulator-5v0-vcc-usb-otg {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = <&gpio0 RK_PA5 GP

Re: [PATCH 2/2] board: rockchip: Add Radxa ROCK 3B

[Kever Yang]

On 2024/7/31 15:28, Jonas Karlman wrote:

The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Features tested on ROCK 3B 8GB v1.51 (both variants):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3568-rock-3b-u-boot.dtsi |  15 
  board/rockchip/evb_rk3568/MAINTAINERS   |   6 ++
  configs/rock-3b-rk3568_defconfig| 100 
  doc/board/rockchip/rockchip.rst |   3 +-
  4 files changed, 123 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
  create mode 100644 configs/rock-3b-rk3568_defconfig

diff --git a/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi 
b/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
new file mode 100644
index ..b1f324282bac
--- /dev/null
+++ b/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&sdhci {
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
diff --git a/board/rockchip/evb_rk3568/MAINTAINERS 
b/board/rockchip/evb_rk3568/MAINTAINERS
index ba4884db8e12..588134ecb27a 100644
--- a/board/rockchip/evb_rk3568/MAINTAINERS
+++ b/board/rockchip/evb_rk3568/MAINTAINERS
@@ -70,6 +70,12 @@ F:   configs/rock-3a-rk3568_defconfig
  F:arch/arm/dts/rk3568-rock-3a.dts
  F:arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
  
+ROCK-3B

+M: Jonas Karlman 
+S: Maintained
+F: configs/rock-3b-rk3568_defconfig
+F: arch/arm/dts/rk3568-rock-3b*
+
  ROCK-3C
  M:Jonas Karlman 
  M:Maxim Moskalets 
diff --git a/configs/rock-3b-rk3568_defconfig b/configs/rock-3b-rk3568_defconfig
new file mode 100644
index ..937796811a97
--- /dev/null
+++ b/configs/rock-3b-rk3568_defconfig
@@ -0,0 +1,100 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3568-rock-3b"
+CONFIG_ROCKCHIP_RK3568=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xFE66
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-rock-3b.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_POWEROFF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ROCKUSB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_SPL_CLK=y
+# CONFIG_USB_FUNCTION_FASTBOOT is not set
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=4
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_NVME_PCI=y
+CONFIG_PCIE_DW_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_FAN53555=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_SPL_RAM=y
+CONFIG_SCSI=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SFC=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_FUNCTION_ROCKUSB=y
+CONFIG_ERRNO_STR=y
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index eadca0ceb2a5..3febebd0b830 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -118,7 +118,8 @@ List 

Re: [PATCH 2/2] board: rockchip: Add Xunlong Orange Pi 3B

[Kever Yang]

On 2024/7/31 17:03, Jonas Karlman wrote:

From: Ricardo Pardini 

The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

The two hw revisions use different io-voltage for Ethernet PHY and can
be identified using GPIO4_C4:
- v1.1.1: x (internal pull-down)
- v2.1:   PHY_RESET (external pull-up)

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both hw revisions.

Minimal DTs that includ DT from dts/upstream is added to support booting
from both hw revision and only set Ethernet PHY io-voltage when the hw
revision is detected at runtime. A side-affect of this is that defconfig
show OF_UPSTREAM=n, however dts/upstream DTs is used for this board.

Features tested on Orange Pi 3B 4GB (v1.1.1 and v2.1):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB host

Signed-off-by: Ricardo Pardini 
Co-developed-by: Jonas Karlman 
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi   | 14 +++
  .../dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi   |  3 +
  arch/arm/dts/rk3566-orangepi-3b-v1.1.dts  |  3 +
  .../dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi   |  3 +
  arch/arm/dts/rk3566-orangepi-3b-v2.1.dts  |  3 +
  arch/arm/dts/rk3566-orangepi-3b.dts   |  5 +
  arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
  board/xunlong/orangepi-3b-rk3566/Kconfig  | 12 +++
  board/xunlong/orangepi-3b-rk3566/MAINTAINERS  |  6 ++
  board/xunlong/orangepi-3b-rk3566/Makefile |  3 +
  .../orangepi-3b-rk3566/orangepi-3b-rk3566.c   | 77 +++
  configs/orangepi-3b-rk3566_defconfig  | 98 +++
  doc/board/rockchip/rockchip.rst   |  1 +
  13 files changed, 234 insertions(+)
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
  create mode 100644 arch/arm/dts/rk3566-orangepi-3b.dts
  create mode 100644 board/xunlong/orangepi-3b-rk3566/Kconfig
  create mode 100644 board/xunlong/orangepi-3b-rk3566/MAINTAINERS
  create mode 100644 board/xunlong/orangepi-3b-rk3566/Makefile
  create mode 100644 board/xunlong/orangepi-3b-rk3566/orangepi-3b-rk3566.c
  create mode 100644 configs/orangepi-3b-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
new file mode 100644
index ..e44b699af720
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk356x-u-boot.dtsi"
+
+&gpio4 {
+   bootph-pre-ram;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
new file mode 100644
index ..50ea6ede7285
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3566-orangepi-3b-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts 
b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
new file mode 100644
index ..f97e33bd8108
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
new file mode 100644
index ..50ea6ede7285
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3566-orangepi-3b-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts 
b/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
new file mode 100644
index ..0031e2477abf
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
diff --git a/arch/arm/dts/rk3566-orangepi-3b.dts 
b/arch/arm/dts/rk3566-orangepi-3b.dts
new file mode 100644
index ..44b9a9c89f0b
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b.dts
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
b/arch/arm/mach-rockchip/rk3568/Kconfig
index 0f32f243be4e..899cf909fbb9 100644
--- a/arch/arm/mach-rockchip/rk3568/Kconfig
+++ b/arch/arm/mach-rockchip/rk3568/Kconfig
@@ -37,6 +37,11 @@ config TARGET_RADXA_ZERO_3_RK3566
help
  Radxa ZERO 3W/3E single board computers with a RK3566 SoC.
  
+config TARGET_ORANGEPI_

Re: [PATCH 1/2] arm64: dts: rockchip: Add Xunlong Orange Pi 3B

[Kever Yang]

On 2024/7/31 17:03, Jonas Karlman wrote:

The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240626230319.1425316-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: d79d713d602e8b32cf935ddfdf61769cb74ba1dc ]

(cherry picked from commit 9defe71f2674f82c27a8d4593d8c5851ab5d51e7)

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  .../rockchip/rk3566-orangepi-3b-v1.1.dts  |  29 +
  .../rockchip/rk3566-orangepi-3b-v2.1.dts  |  70 ++
  .../arm64/rockchip/rk3566-orangepi-3b.dtsi| 678 ++
  3 files changed, 777 insertions(+)
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
new file mode 100644
index ..074e93bd4b85
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-orangepi-3b.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 3B v1.1";
+   compatible = "xunlong,orangepi-3b-v1.1", "xunlong,orangepi-3b", 
"rockchip,rk3566";
+};
+
+&pmu_io_domains {
+   vccio5-supply = <&vcc_3v3>;
+};
+
+&gmac1 {
+   phy-handle = <&rgmii_phy1>;
+   status = "okay";
+};
+
+&mdio1 {
+   rgmii_phy1: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <5>;
+   reset-gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_LOW>;
+   };
+};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
new file mode 100644
index ..d894bff41e61
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-orangepi-3b.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 3B v2.1";
+   compatible = "xunlong,orangepi-3b-v2.1", "xunlong,orangepi-3b", 
"rockchip,rk3566";
+
+   vccio_phy1: regulator-1v8-vccio-phy {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_phy1";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-max-microvolt = <180>;
+   regulator-min-microvolt = <180>;
+   };
+};
+
+&pmu_io_domains {
+   vccio5-supply = <&vccio_phy1>;
+};
+
+&gmac1 {
+   phy-handle = <&rgmii_phy1>;
+   status = "okay";
+};
+
+&mdio1 {
+   rgmii_phy1: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <5>;
+   reset-gpios = <&gpio4 RK_PC4 GPIO_ACTIVE_LOW>;
+   };
+};
+
+&sdmmc1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcmf: wifi@1 {
+   compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+   reg = <1>;
+   interrupt-parent = <&gpio0>;
+   interrupts = ;
+   interrupt-names = "host-wake";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_wake_host_h>;
+   };
+};
+
+&uart1 {
+   bluetooth {
+   compatible = "brcm,bcm4345c5";
+   clocks = <&rk809 1>;
+   clock-names = "lpo";
+   interrupt-parent = <&gpio2>;
+   interrupts = ;
+   interrupt-names = "host-wakeup";
+   device-wakeup-gpios = <&gpio2 RK_PC1 GPIO_ACTIVE_HIGH>;
+   shutdown-gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&bt_reg_on_h &bt_wake_host_h &host_wake_bt_h>;
+   vbat-supply = <&vcc_3v3>;
+   vddio-supply = <&vcc_1v8>;
+   };
+};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi
new file mode 100644
index ..d539570f531e
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi
@@ -0,0 +1,678 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 3B";
+   compatible = "xunlong,orangepi-3b", "rockchip,rk3566";
+
+   aliases {
+   ethernet0 = &gmac1;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
+   mmc2 = &sdmmc1;
+   };
+
+   chos

[PATCH 3/8] net: dc2114x: set the card number to start at zero

[Hanyuan Zhao]

Otherwise the number might get kind of weird.

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

diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index 7f0715429f..cf9f78163a 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -561,7 +561,7 @@ static int dc2114x_read_rom_hwaddr(struct udevice *dev)
 
 static int dc2114x_bind(struct udevice *dev)
 {
-   static int card_number;
+   static int card_number = 0;
char name[16];
 
sprintf(name, "dc2114x#%u", card_number++);
-- 
2.39.2

[PATCH 2/8] net: dc2114x: get mac address from environment

[Hanyuan Zhao]

Let this old driver work like the other newer network card drivers, loading the
MAC address from environment, which could be more flexible to set.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/dc2114x.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index 3704d2e655..7f0715429f 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -478,8 +478,16 @@ static int dc2114x_start(struct udevice *dev)
 {
struct eth_pdata *plat = dev_get_plat(dev);
struct dc2114x_priv *priv = dev_get_priv(dev);
+   int rval;
 
-   memcpy(priv->enetaddr, plat->enetaddr, sizeof(plat->enetaddr));
+   if(!priv->enetaddr) {
+   rval = eth_env_get_enetaddr("ethaddr", priv->enetaddr);
+
+   if (!rval) {
+   printf("dc2114x: Err: please set a valid MAC 
address\n");
+   return -EINVAL;
+   }
+   }
 
 #if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
/* Ensure we're not sleeping. */
@@ -574,9 +582,6 @@ static int dc2114x_probe(struct udevice *dev)
iobase &= ~0xf;
 
debug("dc2114x: DEC 2114x PCI Device @0x%x\n", iobase);
-
-   priv->devno = dev;
-   priv->enetaddr = plat->enetaddr;
priv->iobase = (void __iomem *)dm_pci_mem_to_phys(dev, iobase);
 
command = PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
@@ -589,6 +594,9 @@ static int dc2114x_probe(struct udevice *dev)
 
dm_pci_write_config8(dev, PCI_LATENCY_TIMER, 0x60);
 #endif
+
+   priv->devno = dev;
+   priv->enetaddr = plat->enetaddr;
return 0;
 }
 
-- 
2.39.2

[PATCH 4/8] net: dc2114x: add support for CPUs that have cache between the memory and the card

[Hanyuan Zhao]

This commit adds support for the MIPS and LoongArch CPUs, which would use cache
after they jump into U-Boot. This commit requests the CPU to return the
addresses in uncached windows and flushes the cache in need, to make sure the
memory between the CPU and the network card is in consistency.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/dc2114x.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index cf9f78163a..0b3000cc1d 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,9 +95,17 @@ struct de4x5_desc {
u32 next;
 };
 
+/* Assigned for network card's ring buffer:
+ * Some CPU might treat these memories as cached, and changes to these memories
+ * won't immediately be visible to each other. It is necessary to ensure that
+ * these memories between the CPU and the network card are marked as uncached.
+ */
+static struct de4x5_desc rx_ring[NUM_RX_DESC] __aligned(32);
+static struct de4x5_desc tx_ring[NUM_TX_DESC] __aligned(32);
+
 struct dc2114x_priv {
-   struct de4x5_desc rx_ring[NUM_RX_DESC] __aligned(32);
-   struct de4x5_desc tx_ring[NUM_TX_DESC] __aligned(32);
+   struct de4x5_desc *rx_ring; /* Must be uncached to CPU */
+   struct de4x5_desc *tx_ring; /* Must be uncached to CPU */
int rx_new; /* RX descriptor ring pointer */
int tx_new; /* TX descriptor ring pointer */
char rx_ring_size;
@@ -276,7 +285,12 @@ static int read_srom(struct dc2114x_priv *priv, u_long 
ioaddr, int index)
 
 static void send_setup_frame(struct dc2114x_priv *priv)
 {
-   char setup_frame[SETUP_FRAME_LEN];
+   /* We are writing setup frame and these changes should be visible to the
+* network card immediately. So let's directly read/write through the
+* uncached window.
+*/
+   char __setup_frame[SETUP_FRAME_LEN] __aligned(32);
+   char *setup_frame = (char 
*)map_physmem((phys_addr_t)virt_to_phys(__setup_frame), 0, MAP_NOCACHE);
char *pa = &setup_frame[0];
int i;
 
@@ -337,6 +351,9 @@ static int dc21x4x_send_common(struct dc2114x_priv *priv, 
void *packet, int leng
goto done;
}
 
+   /* Packet should be visible to the network card */
+   flush_dcache_range((phys_addr_t)packet, (phys_addr_t)(packet + 
RX_BUFF_SZ));
+
priv->tx_ring[priv->tx_new].buf = cpu_to_le32(phys_to_bus(priv->devno,
  (u32)packet));
priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_TER | TD_LS | TD_FS | 
length);
@@ -533,7 +550,8 @@ static int dc2114x_recv(struct udevice *dev, int flags, 
uchar **packetp)
if (!ret)
return 0;
 
-   *packetp = net_rx_packets[priv->rx_new];
+   invalidate_dcache_range((phys_addr_t)net_rx_packets[priv->rx_new], 
(phys_addr_t)(net_rx_packets[priv->rx_new] + RX_BUFF_SZ));
+   *packetp = (uchar *)net_rx_packets[priv->rx_new];
 
return ret - 4;
 }
@@ -597,6 +615,9 @@ static int dc2114x_probe(struct udevice *dev)
 
priv->devno = dev;
priv->enetaddr = plat->enetaddr;
+   priv->rx_ring = (struct de4x5_desc 
*)map_physmem((phys_addr_t)virt_to_phys(rx_ring), 0, MAP_NOCACHE);
+   priv->tx_ring = (struct de4x5_desc 
*)map_physmem((phys_addr_t)virt_to_phys(tx_ring), 0, MAP_NOCACHE);
+
return 0;
 }
 
-- 
2.39.2

[PATCH 5/8] net: dc2114x: remove unused lines and change the var and print types

[Hanyuan Zhao]

This commit fixes a problem that even though the network card does not report
any issues in transmitting a setup frame, the driver prints the error status
every time. Let's set it for debug use.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/dc2114x.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index 0b3000cc1d..8a285742a1 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -311,7 +311,7 @@ static void send_setup_frame(struct dc2114x_priv *priv)
}
 
priv->tx_ring[priv->tx_new].buf = cpu_to_le32(phys_to_bus(priv->devno,
- (u32)&setup_frame[0]));
+ 
(phys_addr_t)&setup_frame[0]));
priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_TER | TD_SET | 
SETUP_FRAME_LEN);
priv->tx_ring[priv->tx_new].status = cpu_to_le32(T_OWN);
 
@@ -326,7 +326,7 @@ static void send_setup_frame(struct dc2114x_priv *priv)
}
 
if (le32_to_cpu(priv->tx_ring[priv->tx_new].status) != 0x7FFF) {
-   printf("TX error status2 = 0x%08X\n",
+   debug("TX error status2 = 0x%08X\n",
   le32_to_cpu(priv->tx_ring[priv->tx_new].status));
}
 
@@ -355,7 +355,7 @@ static int dc21x4x_send_common(struct dc2114x_priv *priv, 
void *packet, int leng
flush_dcache_range((phys_addr_t)packet, (phys_addr_t)(packet + 
RX_BUFF_SZ));
 
priv->tx_ring[priv->tx_new].buf = cpu_to_le32(phys_to_bus(priv->devno,
- (u32)packet));
+ (phys_addr_t)packet));
priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_TER | TD_LS | TD_FS | 
length);
priv->tx_ring[priv->tx_new].status = cpu_to_le32(T_OWN);
 
@@ -426,7 +426,7 @@ static int dc21x4x_init_common(struct dc2114x_priv *priv)
priv->rx_ring[i].status = cpu_to_le32(R_OWN);
priv->rx_ring[i].des1 = cpu_to_le32(RX_BUFF_SZ);
priv->rx_ring[i].buf = cpu_to_le32(phys_to_bus(priv->devno,
-(u32)net_rx_packets[i]));
+(phys_addr_t)net_rx_packets[i]));
priv->rx_ring[i].next = 0;
}
 
@@ -445,9 +445,9 @@ static int dc21x4x_init_common(struct dc2114x_priv *priv)
priv->tx_ring[priv->tx_ring_size - 1].des1 |= cpu_to_le32(TD_TER);
 
/* Tell the adapter where the TX/RX rings are located. */
-   dc2114x_outl(priv, phys_to_bus(priv->devno, (u32)&priv->rx_ring),
+   dc2114x_outl(priv, phys_to_bus(priv->devno, (phys_addr_t)priv->rx_ring),
 DE4X5_RRBA);
-   dc2114x_outl(priv, phys_to_bus(priv->devno, (u32)&priv->tx_ring),
+   dc2114x_outl(priv, phys_to_bus(priv->devno, (phys_addr_t)priv->tx_ring),
 DE4X5_TRBA);
 
start_de4x5(priv);
@@ -493,7 +493,6 @@ static struct pci_device_id supported[] = {
 
 static int dc2114x_start(struct udevice *dev)
 {
-   struct eth_pdata *plat = dev_get_plat(dev);
struct dc2114x_priv *priv = dev_get_priv(dev);
int rval;
 
-- 
2.39.2

[PATCH 7/8] net: dc2114x: allow users to decide how to tx packets according to IP core

[Hanyuan Zhao]

Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. Originally this
driver uses only one tx descriptor and organizes it as a ring buffer,
which would lead to a problem that one packet would be sent twice.
This commit adds support to prevent this bug if you are using IP
cores with this issue, by using multiple tx descriptors and
organizing them as a real well-defined ring buffer.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/Kconfig   | 13 +
 drivers/net/dc2114x.c | 17 -
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index d79d8ad9c4..89bd77da19 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -759,6 +759,19 @@ config TULIP_IGNORE_TX_NO_CARRIER
  of this IP core do not detect this error anymore. Say Y to this could
  disable handling of this error.
 
+config TULIP_MULTIPLE_TX_DESC
+   bool "Use multiple tx descriptors"
+   depends on TULIP
+   default n
+   help
+ Some IP cores of dc2114x or its variants do not comply so well with
+ the behaviors described by the official document. Originally this
+ driver uses only one tx descriptor and organizes it as a ring buffer,
+ which would lead to a problem that one packet would be sent twice.
+ Say Y to this could prevent this bug if you are using IP cores with
+ this issue, by using multiple tx descriptors and organizing them as
+ a real well-defined ring buffer.
+
 config XILINX_AXIEMAC
select PHYLIB
select MII
diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index dc28712221..11dea9b4d7 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -78,10 +78,15 @@
 #else
 #define phys_to_bus(dev, a)dm_pci_phys_to_mem((dev), (a))
 #endif
+
+/* Number of TX descriptors   */
+#if CONFIG_IS_ENABLED(TULIP_MULTIPLE_TX_DESC)
+#define NUM_TX_DESC 4
+#else
+#define NUM_TX_DESC 1
 #endif
 
 #define NUM_RX_DESC PKTBUFSRX
-#define NUM_TX_DESC 1  /* Number of TX descriptors   */
 #define RX_BUFF_SZ  PKTSIZE_ALIGN
 
 #define TOUT_LOOP   100
@@ -312,7 +317,12 @@ static void send_setup_frame(struct dc2114x_priv *priv)
 
priv->tx_ring[priv->tx_new].buf = cpu_to_le32(phys_to_bus(priv->devno,
  
(phys_addr_t)&setup_frame[0]));
+#if CONFIG_IS_ENABLED(TULIP_MULTIPLE_TX_DESC)
+   priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_SET | 
SETUP_FRAME_LEN);
+   priv->tx_ring[priv->tx_ring_size - 1].des1 |= cpu_to_le32(TD_TER);
+#else
priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_TER | TD_SET | 
SETUP_FRAME_LEN);
+#endif
priv->tx_ring[priv->tx_new].status = cpu_to_le32(T_OWN);
 
dc2114x_outl(priv, POLL_DEMAND, DE4X5_TPD);
@@ -356,7 +366,12 @@ static int dc21x4x_send_common(struct dc2114x_priv *priv, 
void *packet, int leng
 
priv->tx_ring[priv->tx_new].buf = cpu_to_le32(phys_to_bus(priv->devno,
  (phys_addr_t)packet));
+#if CONFIG_IS_ENABLED(TULIP_MULTIPLE_TX_DESC)
+   priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_LS | TD_FS | length);
+   priv->tx_ring[priv->tx_ring_size - 1].des1 |= cpu_to_le32(TD_TER);
+#else
priv->tx_ring[priv->tx_new].des1 = cpu_to_le32(TD_TER | TD_LS | TD_FS | 
length);
+#endif
priv->tx_ring[priv->tx_new].status = cpu_to_le32(T_OWN);
 
dc2114x_outl(priv, POLL_DEMAND, DE4X5_TPD);
-- 
2.39.2

[PATCH 6/8] net: dc2114x: allow users to decide whether to detect the tx No Carrier errors

[Hanyuan Zhao]

Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. A packet could be
sent successfully but reported with No Carrier error. Latest drivers
of this IP core have not detect this error anymore.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/Kconfig   | 11 +++
 drivers/net/dc2114x.c |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 41b7c66105..d79d8ad9c4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -748,6 +748,17 @@ config TULIP_SUPPORT_NON_PCI
  Say Y to this and you can run this driver on platforms that do not
  have PCI controllers.
 
+config TULIP_IGNORE_TX_NO_CARRIER
+   bool "Ignore tx no carrier error"
+   depends on TULIP
+   default n
+   help
+ Some IP cores of dc2114x or its variants do not comply so well with
+ the behaviors described by the official document. A packet could be
+ sent successfully but reported with No Carrier error. Latest drivers
+ of this IP core do not detect this error anymore. Say Y to this could
+ disable handling of this error.
+
 config XILINX_AXIEMAC
select PHYLIB
select MII
diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index 8a285742a1..dc28712221 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -371,7 +371,9 @@ static int dc21x4x_send_common(struct dc2114x_priv *priv, 
void *packet, int leng
 
if (le32_to_cpu(priv->tx_ring[priv->tx_new].status) & TD_ES) {
priv->tx_ring[priv->tx_new].status = 0x0;
+#if !CONFIG_IS_ENABLED(TULIP_IGNORE_TX_NO_CARRIER)
goto done;
+#endif
}
 
status = length;
-- 
2.39.2

[PATCH 8/8] net: dc2114x: remove the pass all multicast flag in operation mode settings

[Hanyuan Zhao]

Remove the OMR_PM flag and choose 16 perfect filtering mode since in
modern networks there're plenty of multicasts and set ORM_PM flag will
increase the dc2114x's workload and ask the U-Boot to handle packets
not related to itself. And most of the time, U-Boot does not need this
feature.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/dc2114x.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index 11dea9b4d7..e1edda8e19 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -437,7 +437,16 @@ static int dc21x4x_init_common(struct dc2114x_priv *priv)
return -1;
}
 
-   dc2114x_outl(priv, OMR_SDP | OMR_PS | OMR_PM, DE4X5_OMR);
+   /* 2024-07:
+* Remove the OMR_PM flag and choose 16 perfect filtering mode since in
+* modern networks there're plenty of multicasts and set ORM_PM flag 
will
+* increase the dc2114x's workload and ask the U-Boot to handle packets
+* not related to itself. And most of the time, U-Boot does not need 
this
+* feature.
+*
+* A better way: let user to decide whether to have this flag.
+*/
+   dc2114x_outl(priv, OMR_SDP | OMR_PS, DE4X5_OMR);
 
for (i = 0; i < NUM_RX_DESC; i++) {
priv->rx_ring[i].status = cpu_to_le32(R_OWN);
-- 
2.39.2

[PATCH 1/8] net: dc2114x: add support for platforms that don't have pci controllers

[Hanyuan Zhao]

There're a few ethernet IP cores which have the same functions with dc2114x,
and can be connected to CPU by AXI or other buses. This commit adds support
for the platforms that do not have PCI controllers, using MMIO to communicate
with the dc2114x IP core.

Signed-off-by: Hanyuan Zhao 
---
 drivers/net/Kconfig   |  8 
 drivers/net/dc2114x.c | 43 ++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 69ae7c0750..41b7c66105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -740,6 +740,14 @@ config TULIP
help
  This driver supports DEC DC2114x Fast ethernet chips.
 
+config TULIP_SUPPORT_NON_PCI
+   bool "No PCI controller"
+   depends on TULIP
+   default n
+   help
+ Say Y to this and you can run this driver on platforms that do not
+ have PCI controllers.
+
 config XILINX_AXIEMAC
select PHYLIB
select MII
diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c
index ce028f451f..3704d2e655 100644
--- a/drivers/net/dc2114x.c
+++ b/drivers/net/dc2114x.c
@@ -72,7 +72,12 @@
 
 #define POLL_DEMAND1
 
+#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
+#define phys_to_bus(dev, a)virt_to_phys((volatile const void *)(a))
+#else
 #define phys_to_bus(dev, a)dm_pci_phys_to_mem((dev), (a))
+#endif
+#endif
 
 #define NUM_RX_DESC PKTBUFSRX
 #define NUM_TX_DESC 1  /* Number of TX descriptors   */
@@ -461,11 +466,13 @@ static void read_hw_addr(struct dc2114x_priv *priv)
}
 }
 
+#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
 static struct pci_device_id supported[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_TULIP_FAST) },
{ PCI_DEVICE(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21142) },
{ }
 };
+#endif
 
 static int dc2114x_start(struct udevice *dev)
 {
@@ -474,8 +481,10 @@ static int dc2114x_start(struct udevice *dev)
 
memcpy(priv->enetaddr, plat->enetaddr, sizeof(plat->enetaddr));
 
+#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
/* Ensure we're not sleeping. */
dm_pci_write_config8(dev, PCI_CFDA_PSM, WAKEUP);
+#endif
 
return dc21x4x_init_common(priv);
 }
@@ -485,8 +494,9 @@ static void dc2114x_stop(struct udevice *dev)
struct dc2114x_priv *priv = dev_get_priv(dev);
 
dc21x4x_halt_common(priv);
-
+#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
dm_pci_write_config8(dev, PCI_CFDA_PSM, SLEEP);
+#endif
 }
 
 static int dc2114x_send(struct udevice *dev, void *packet, int length)
@@ -555,6 +565,8 @@ static int dc2114x_probe(struct udevice *dev)
 {
struct eth_pdata *plat = dev_get_plat(dev);
struct dc2114x_priv *priv = dev_get_priv(dev);
+
+#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
u16 command, status;
u32 iobase;
 
@@ -576,9 +588,22 @@ static int dc2114x_probe(struct udevice *dev)
}
 
dm_pci_write_config8(dev, PCI_LATENCY_TIMER, 0x60);
+#endif
+   return 0;
+}
+
+#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
+static int dc2114x_of_to_plat(struct udevice *dev)
+{
+   struct eth_pdata *plat = dev_get_plat(dev);
+   struct dc2114x_priv *priv = dev_get_priv(dev);
+
+   plat->iobase = 
(phys_addr_t)map_physmem((phys_addr_t)devfdt_get_addr(dev), 0, MAP_NOCACHE);
+   priv->iobase = (void*)plat->iobase;
 
return 0;
 }
+#endif
 
 static const struct eth_ops dc2114x_ops = {
.start  = dc2114x_start,
@@ -589,9 +614,23 @@ static const struct eth_ops dc2114x_ops = {
.read_rom_hwaddr = dc2114x_read_rom_hwaddr,
 };
 
+#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
+static const struct udevice_id dc2114x_eth_ids[] = {
+   { .compatible = "dec,dmfe" },
+   { .compatible = "tulip,dmfe" },
+   { .compatible = "dec,dc2114x" },
+   { .compatible = "tulip,dc2114x" },
+   { }
+};
+#endif
+
 U_BOOT_DRIVER(eth_dc2114x) = {
.name   = "eth_dc2114x",
.id = UCLASS_ETH,
+#if CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
+   .of_match   = dc2114x_eth_ids,
+   .of_to_plat = dc2114x_of_to_plat,
+#endif
.bind   = dc2114x_bind,
.probe  = dc2114x_probe,
.ops= &dc2114x_ops,
@@ -599,4 +638,6 @@ U_BOOT_DRIVER(eth_dc2114x) = {
.plat_auto  = sizeof(struct eth_pdata),
 };
 
+#if !CONFIG_IS_ENABLED(TULIP_SUPPORT_NON_PCI)
 U_BOOT_PCI_DEVICE(eth_dc2114x, supported);
+#endif
-- 
2.39.2

Re: [PATCH] arm: dts: rockchip: disable "usb_host0_ohci" to make boot faster for Radxa ROCK 3A

[Kever Yang]

Hi Naoki,

On 2024/8/2 10:49, FUKAUMI Naoki wrote:

on-board USB 2.0 hub, FE1.1s, has Transaction Translator which can
handle USB 1.x devices via "usb_host0_ehci". so we can omit
"usb_host0_ohci" and make boot faster (a little).


The OHCI is in use when the direct connect device is USB1.1; and if the 
board


connect with usb2.0 hub, then only EHCI is working and OHCI has no use.




=> usb start
starting USB...
Bus usb@fd00: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd80: USB EHCI 1.00
Bus usb@fd88: USB EHCI 1.00
Bus usb@fd8c: USB OHCI 1.0
scanning bus usb@fd00 for devices... 1 USB Device(s) found
scanning bus usb@fd80 for devices... 2 USB Device(s) found
scanning bus usb@fd88 for devices... 1 USB Device(s) found
scanning bus usb@fd8c for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
   1  Hub (5 Gb/s, 0mA)
  U-Boot XHCI Host Controller

   1  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-2  Hub (480 Mb/s, 100mA)
 USB 2.0 Hub

   1  Hub (480 Mb/s, 0mA)
  u-boot EHCI Host Controller

   1  Hub (12 Mb/s, 0mA)
   |   U-Boot Root Hub
   |
   +-2  Hub (12 Mb/s, 100mA)
 |  ALCOR Generic USB Hub
 |
 +-3  Mass Storage (12 Mb/s, 300mA)
  JetFlash Mass Storage Device 02K1RNH5MJFV4TX6

=> usb reset
resetting USB...
Host not halted after 16000 microseconds.
Bus usb@fd00: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd80: USB EHCI 1.00
Bus usb@fd88: USB EHCI 1.00
Bus usb@fd8c: USB OHCI 1.0
scanning bus usb@fd00 for devices... 1 USB Device(s) found
scanning bus usb@fd80 for devices... 4 USB Device(s) found
scanning bus usb@fd88 for devices... 1 USB Device(s) found
scanning bus usb@fd8c for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
   1  Hub (5 Gb/s, 0mA)
  U-Boot XHCI Host Controller

   1  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-2  Hub (480 Mb/s, 100mA)
 |   USB 2.0 Hub
 |
 +-3  Hub (12 Mb/s, 100mA)
   |  ALCOR Generic USB Hub
   |
   +-4  Mass Storage (12 Mb/s, 300mA)
JetFlash Mass Storage Device 02K1RNH5MJFV4TX6

   1  Hub (480 Mb/s, 0mA)
  u-boot EHCI Host Controller

   1  Hub (12 Mb/s, 0mA)
   U-Boot Root Hub

Signed-off-by: FUKAUMI Naoki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi 
b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
index 9d18f5d0b36..9078b9a67a2 100644
--- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
@@ -40,3 +40,7 @@
spi-tx-bus-width = <1>;
};
  };
+
+&usb_host0_ohci {
+   status = "disabled";
+};

Re: [PATCH] arm: dts: rockchip: fix dts for Radxa ROCK 4C+

[Kever Yang]

On 2024/8/9 06:19, FUKAUMI Naoki wrote:

Radxa ROCK Pi 4 series and Radxa ROCK 4C+ are not compatible.


A little bit more detail about why not compatible?

The eMMC is different?

Thanks,

- Kever


add
rk3399-rock-pi-4-u-boot.dtsi contents and remove dependency of it.

no functional change is intended.

Fixes: 71a95e2efd30 ("arm: dts: rockchip: add Radxa ROCK 4C+")
Suggested-by: Dragan Simic 
Signed-off-by: FUKAUMI Naoki 
---
  arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi 
b/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi
index 5ec15a845c1..50dae5cb5ef 100644
--- a/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi
@@ -1,8 +1,10 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// SPDX-License-Identifier: GPL-2.0+
  /*
+ * Copyright (C) 2019 Jagan Teki 
   * Copyright (c) 2023 Radxa Limited
   */
-#include "rk3399-rock-pi-4-u-boot.dtsi"
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
  
  &pcfg_pull_none_18ma {

bootph-pre-ram;
@@ -14,6 +16,12 @@
bootph-some-ram;
  };
  
+&sdhci {

+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+};
+
  &spi1 {
status = "okay";
  
@@ -25,3 +33,7 @@

spi-max-frequency = <1000>;
};
  };
+
+&vdd_log {
+   regulator-init-microvolt = <95>;
+};

Re: [PATCH] arm: dts: rockchip: remove upstreamed props for Radxa ROCK 3A

[Kever Yang]

On 2024/8/6 09:18, FUKAUMI Naoki wrote:

"sfc" node was already upstreamed. remove unnecessary properties from
u-boot.dtsi.

Signed-off-by: FUKAUMI Naoki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 9 -
  1 file changed, 9 deletions(-)

diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi 
b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
index 9d18f5d0b36..4df40eec975 100644
--- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
@@ -26,17 +26,8 @@
  };
  
  &sfc {

-   #address-cells = <1>;
-   #size-cells = <0>;
-   status = "okay";
-
flash@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
bootph-pre-ram;
bootph-some-ram;
-   spi-max-frequency = <2400>;
-   spi-rx-bus-width = <4>;
-   spi-tx-bus-width = <1>;
};
  };

Re: [PATCH] arm: dts: rockchip: remove upstreamed props for Radxa ROCK 5B

[Kever Yang]

On 2024/8/6 11:37, FUKAUMI Naoki wrote:

"usb_host1_xhci" and related node were already upstreamed. remove
unnecessary properties from u-boot.dtsi.

Signed-off-by: FUKAUMI Naoki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 17 -
  1 file changed, 17 deletions(-)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 8e318e624a8..4dd17ff408c 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -39,18 +39,6 @@
status = "okay";
  };
  
-&u2phy1 {

-   status = "okay";
-};
-
-&u2phy1_otg {
-   status = "okay";
-};
-
-&usbdp_phy1 {
-   status = "okay";
-};
-
  &usbdp_phy0 {
status = "okay";
  };
@@ -60,8 +48,3 @@
maximum-speed = "high-speed";
status = "okay";
  };
-
-&usb_host1_xhci {
-   dr_mode = "host";
-   status = "okay";
-};

Re: [PATCH v3 3/7] board: rock5b-rk3588: add USB-C controller support

[Kever Yang]

On 2024/8/3 01:59, Sebastian Reichel wrote:

Enable support for the fusb302 USB Type-C controller.

This will do early USB PD (power deliver) negotiation, which must happen
within 5 seconds after the USB-C connector has plugged in according to
the specification. It takes almost 5 seconds to go through the bootchain
on Rock 5B and jump to the operating system. When the Linux initializes
the fusb302 usually 20-30 seconds have gone since the device has been
plugged, which is far too late. The USB PD power source reacts with a
hard reset, which disables VBUS for some time. This is not a problem for
a battery driven device, but Rock 5B will loose its power-supply and
reset. By initializing PD in U-Boot, this can be avoided.

Signed-off-by: Sebastian Reichel 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/radxa/rock5b-rk3588/Makefile|  6 
  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 35 +++
  2 files changed, 41 insertions(+)
  create mode 100644 board/radxa/rock5b-rk3588/Makefile
  create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c

diff --git a/board/radxa/rock5b-rk3588/Makefile 
b/board/radxa/rock5b-rk3588/Makefile
new file mode 100644
index ..95d813596da4
--- /dev/null
+++ b/board/radxa/rock5b-rk3588/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2022 Collabora Ltd.
+#
+
+obj-y += rock5b-rk3588.o
diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
new file mode 100644
index ..1c17ae93c76c
--- /dev/null
+++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023-2024 Collabora Ltd.
+ */
+
+#include 
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   /*
+* This will do early USB PD (power deliver) negotiation, which must
+* happen within 5 seconds after the USB-C connector has plugged in
+* according to the specification. It takes almost 5 seconds to go
+* through the bootchain on Rock 5B and jump to the operating system.
+* When the Linux initializes the fusb302 usually 20-30 seconds have
+* gone since the device has been plugged, which is far too late.
+*
+* The USB PD power source reacts with a hard reset, which disables
+* VBUS for some time. This is not a problem for a battery driven
+* device, but Rock 5B will loose its power-supply and reset. By
+* initializing PD in U-Boot, this can be avoided.
+*/
+   ret = tcpm_get("usb-typec@22", &dev);
+   if (ret) {
+   printf("Failed to probe Type-C controller\n");
+   return 0;
+   }
+
+   return 0;
+}
+#endif

Re: [PATCH v3 5/7] rockchip: rk3588-rock-5b: Add USB-C controller to u-boot.dtsi

[Kever Yang]

On 2024/8/3 01:59, Sebastian Reichel wrote:

Add USB-C controller (fusb302), which will be used by U-Boot to
initialize USB-PD. This is needed, because USB-PD communication
must happen within 5 seconds after the USB-C connector got plugged.
On my Rock 5B it often takes 5 seconds to jump to the Linux binary,
so it must happen before Linux is initialized.

This adds the DT node to the U-Boot specific file, since the Linux
kernel DT currently does not describe it to avoid a system reset.
The plan is to add it to the Linux DT with status = 'fail' and then
let U-Boot mark it as status = 'okay' if it properly dealt with
early USB-PD initialization. Until the Kernel DT has the node, let's
add it in U-Boot to get things going.

Signed-off-by: Sebastian Reichel 

Reviewed-by: Kever Yang 

Thanks,
- Kever

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

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 8e318e624a85..e93795359ece 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -3,6 +3,7 @@
   * Copyright (c) 2023 Collabora Ltd.
   */
  
+#include 

  #include "rk3588-u-boot.dtsi"
  
  &fspim2_pins {

@@ -65,3 +66,30 @@
dr_mode = "host";
status = "okay";
  };
+
+&i2c4 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c4m1_xfer>;
+   status = "okay";
+
+   usbc0: usb-typec@22 {
+   compatible = "fcs,fusb302";
+   reg = <0x22>;
+   interrupt-parent = <&gpio3>;
+   interrupts = ;
+   pinctrl-names = "default";
+   status = "okay";
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   data-role = "dual";
+   power-role = "sink";
+   try-power-role = "sink";
+   op-sink-microwatt = <100>;
+   sink-pdos =
+   ,
+   ;
+   };
+   };
+};

Re: [PATCH v3 6/7] rockchip: rock5b-rk3588: Enable USB-C PD support

[Kever Yang]

On 2024/8/3 01:59, Sebastian Reichel wrote:

Now that all code has been prepared update the default configuration to
make use of it.

Signed-off-by: Sebastian Reichel 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/rock5b-rk3588_defconfig | 5 +
  1 file changed, 5 insertions(+)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index fc118cea7bae..f056728d338b 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -23,6 +23,7 @@ CONFIG_FIT_VERBOSE=y
  CONFIG_SPL_FIT_SIGNATURE=y
  CONFIG_SPL_LOAD_FIT=y
  CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_OF_BOARD_SETUP=y
  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb"
  # CONFIG_DISPLAY_CPUINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
@@ -102,3 +103,7 @@ CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DOWNLOAD=y
  CONFIG_USB_FUNCTION_ROCKUSB=y
  CONFIG_ERRNO_STR=y
+CONFIG_TYPEC_TCPM=y
+CONFIG_TYPEC_FUSB302=y
+CONFIG_MISC_INIT_R=y
+CONFIG_CMD_TCPM=y

Re: [PATCH v3 4/7] board: rock5b-rk3588: enable USB-C in operating system

[Kever Yang]

On 2024/8/3 01:59, Sebastian Reichel wrote:

Since older U-Boot releases do not negotiate USB PD, the kernel
DT may not enable the USB-C controller by default to avoid a
regression. The plan is to upstream it with 'status = "fail";'
instead. U-Boot should then mark it as 'status = "okay";' if
it negotiated USB PD. Currently existing upstream kernel DTs do
not yet have the USB-C controller at all, so we ignore any
failures.

Signed-off-by: Sebastian Reichel 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
index 1c17ae93c76c..4e926ebf2cb0 100644
--- a/board/radxa/rock5b-rk3588/rock5b-rk3588.c
+++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
@@ -3,6 +3,8 @@
   * Copyright (c) 2023-2024 Collabora Ltd.
   */
  
+#include 

+#include 
  #include 
  
  #ifdef CONFIG_MISC_INIT_R

@@ -33,3 +35,12 @@ int misc_init_r(void)
return 0;
  }
  #endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+   if (IS_ENABLED(CONFIG_MISC_INIT_R))
+   fdt_status_okay_by_compatible(blob, "fcs,fusb302");
+   return 0;
+}
+#endif

Re: [PATCH v2 4/4] board: rockchip: Add Radxa ROCK 5 ITX

[Kever Yang]

On 2024/8/3 05:00, Heiko Stuebner wrote:

The Rock 5 ITX is board in ITX form factor using the RK358 SoC

It can be powered either by 12V, ATX power-supply or PoE.

Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot,
2*2.5Gb PCIe-connected Ethernet NICs.

Display options are 2*HDMI, DP via USB-c, eDP + 2*DSI via PCB connectors.

USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel
connector.

Schematics for the board can be found on
- https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf
- https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf

The naming scheme with the dashes follows Dragan's comment on the mainline
devicetree commit:
 "the name of this board deviates from the standard Radxa naming scheme,
  which is something like "ROCK " thus, "rock-5a" is
  fine, but it should be "rock-5-itx", simply because there's a space
  between "5" and "ITX" in "ROCK 5 ITX"

Signed-off-by: Heiko Stuebner 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi |  22 
  arch/arm/mach-rockchip/rk3588/Kconfig  |  29 ++
  board/radxa/rock-5-itx-rk3588/Kconfig  |  12 +++
  board/radxa/rock-5-itx-rk3588/MAINTAINERS  |   8 ++
  configs/rock-5-itx-rk3588_defconfig| 111 +
  doc/board/rockchip/rockchip.rst|   1 +
  include/configs/rock-5-itx-rk3588.h|  15 +++
  7 files changed, 198 insertions(+)
  create mode 100644 arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
  create mode 100644 board/radxa/rock-5-itx-rk3588/Kconfig
  create mode 100644 board/radxa/rock-5-itx-rk3588/MAINTAINERS
  create mode 100644 configs/rock-5-itx-rk3588_defconfig
  create mode 100644 include/configs/rock-5-itx-rk3588.h

diff --git a/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
new file mode 100644
index 000..1e5c2674e49
--- /dev/null
+++ b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+&fspim2_pins {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
+
+&vcc3v3_mkey {
+   regulator-always-on;
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index e751d64e1a1..0dcf2249fb4 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -185,6 +185,34 @@ config TARGET_ROCK5B_RK3588
  USB PD over USB Type-C
  Size: 100mm x 72mm (Pico-ITX form factor)
  
+config TARGET_ROCK_5_ITX_RK3588

+   bool "Radxa ROCK-5-ITX RK3588 board"
+   select BOARD_LATE_INIT
+   help
+ Radxa ROCK-5-ITX is a Rockchip RK3588 based SBC (Single Board
+ Computer) by Radxa in the ITX formfactor.
+
+ There are variants depending on the DRAM size : from 4G up to 32G.
+
+ Specification:
+
+ Rockchip Rk3588 SoC
+ 4x ARM Cortex-A76, 4x ARM Cortex-A55
+ 4/8/16/24/32GB memory LPDDR5
+ Mali G610MC4 GPU
+ 2x MIPI CSI 2 multiple lanes connector
+ eMMC
+ uSD slot (up to 128GB)
+ M.2 M-key and M.2 E-key connector
+ 4x SATA
+ 2x USB 2.0 + 4x USB 3.0 Type-A, 2x USB 2.0 Panel, 1x USB 3.0 Type-C
+ 2x HDMI 2.1 output, 1x HDMI input
+ DP via Type-C
+ 2x DSI via PCB connector
+ 2x 2.5 Gbps Ethernet port
+ Front-panel connectors for audio and case-power, -leds
+ Powered by either 12V, ATX power-supply or PoE
+
  config TARGET_SIGE7_RK3588
bool "ArmSoM Sige7 RK3588 board"
select BOARD_LATE_INIT
@@ -319,6 +347,7 @@ source "board/pine64/quartzpro64-rk3588/Kconfig"
  source "board/turing/turing-rk1-rk3588/Kconfig"
  source "board/radxa/rock5a-rk3588s/Kconfig"
  source "board/radxa/rock5b-rk3588/Kconfig"
+source "board/radxa/rock-5-itx-rk3588/Kconfig"
  source "board/rockchip/evb_rk3588/Kconfig"
  source "board/rockchip/toybrick_rk3588/Kconfig"
  source "board/theobroma-systems/jaguar_rk3588/Kconfig"
diff --git a/board/radxa/rock-5-itx-rk3588/Kconfig 
b/board/radxa/rock-5-itx-rk3588/Kconfig
new file mode 100644
index 000..f7a7666d531
--- /dev/null
+++ b/board/radxa/rock-5-itx-rk3588/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_ROCK_5_ITX_RK3588
+
+config SYS_BOARD
+   default "rock-5-itx-rk3588"
+
+config SYS_VENDOR
+   default "radxa"
+
+config SYS_CONFIG_NAME
+   default "rock-5-itx-rk3588"
+
+endif
diff --git a/board/radxa/rock-5-itx-rk3588/MAINTAINERS 
b/board/radxa/rock-5-itx-rk3588/MAINTAINERS
new file mode 100644
index 000..1c4f24306a0
--- /dev/null
+++ b/board/radxa/rock-5-itx-rk3588/MAINTAINERS
@@ -0,0 +1,8 @@
+ROCK-5-ITX-RK3588
+M: Heiko Stuebner 
+R: Jonas Karlman 
+S: Maintained
+F: board

Re: [PATCH v3 3/7] board: rock5b-rk3588: add USB-C controller support

[Jonas Karlman]

Hi Sebastian,

On 2024-08-03 18:17, Sebastian Reichel wrote:
> Hi Jonas,
> 
> On Fri, Aug 02, 2024 at 10:42:56PM GMT, Jonas Karlman wrote:
>> On 2024-08-02 19:59, Sebastian Reichel wrote:
>>> Enable support for the fusb302 USB Type-C controller.
>>>
>>> This will do early USB PD (power deliver) negotiation, which must happen
>>> within 5 seconds after the USB-C connector has plugged in according to
>>> the specification. It takes almost 5 seconds to go through the bootchain
>>> on Rock 5B and jump to the operating system. When the Linux initializes
>>> the fusb302 usually 20-30 seconds have gone since the device has been
>>> plugged, which is far too late. The USB PD power source reacts with a
>>> hard reset, which disables VBUS for some time. This is not a problem for
>>> a battery driven device, but Rock 5B will loose its power-supply and
>>> reset. By initializing PD in U-Boot, this can be avoided.
>>>
>>> Signed-off-by: Sebastian Reichel 
>>> ---
>>>  board/radxa/rock5b-rk3588/Makefile|  6 
>>>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 35 +++
>>>  2 files changed, 41 insertions(+)
>>>  create mode 100644 board/radxa/rock5b-rk3588/Makefile
>>>  create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>>
>>> diff --git a/board/radxa/rock5b-rk3588/Makefile 
>>> b/board/radxa/rock5b-rk3588/Makefile
>>> new file mode 100644
>>> index ..95d813596da4
>>> --- /dev/null
>>> +++ b/board/radxa/rock5b-rk3588/Makefile
>>> @@ -0,0 +1,6 @@
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +#
>>> +# Copyright (c) 2022 Collabora Ltd.
>>> +#
>>> +
>>> +obj-y += rock5b-rk3588.o
>>> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
>>> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> new file mode 100644
>>> index ..1c17ae93c76c
>>> --- /dev/null
>>> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> @@ -0,0 +1,35 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2023-2024 Collabora Ltd.
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#ifdef CONFIG_MISC_INIT_R
>>> +int misc_init_r(void)
>>
>> You should not override misc_init_r() here as it will override the
>> rockchip board common misc_init_r() function that read cpuid, set serial
>> and ethernet mac address env vars.

This needs to be addressed if you must add this code.

>>
>> I would suggest you instead of tcpm_get() add something similar to
>>
>> int tcpm_probe_all()
>> {
>>  struct udevice *dev;
>>  struct uclass *uc;
>>  int ret;
>>
>>  ret = uclass_get(UCLASS_TCPM, &uc);
>>  if (ret)
>>  return ret;
>>
>>  for (ret = uclass_first_device_check(UCLASS_TCPM, &dev);
>>   dev;
>>   ret = uclass_next_device_check(&dev)) {
>>  if (ret)
>>  printf("Failed to probe Type-C controller '%s' 
>> (ret=%d)\n",
>> dev->name, ret);
>>  }
>>
>>  return 0;
>> }
>>
>> or if we do not care about the error message this could use
>>
>>  uclass_probe_all(UCLASS_TCPM);
>>
>> and call it from the rockchip board common code in mach-rockchip/board.c
>> directly after the call to regulators_enable_boot_on() in board_init().
>>
>> Alternatively you could call following in a tcpm_post_bind()
>>
>>  dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>>
>> to automatically probe the device as soon as possible after all devices
>> have been bind, this is how the rockchip-io-domain driver does it.
>>
>> Otherwise we need to add custom board code for each board using USB PD,
>> something to avoid.
> 
> All of your suggestions result in any USB-PD controllers being
> probed automatically. I intentionally did not go that way, since
> probing can be quite slow depending on the remote side. For most
> power-supplies it seems to be quite fast, but I've seen a boot
> with one of the supplies being delayed by 2-3 seconds. Seems not
> nice to add this penality for a device not depending on it.

Since you add a cmd you could possible just add a PREBOOT to run that
cmd on boot.

We should try to avoid having to add new code for each board that needs
to negotiate USB PD.

For a more elaborate solution maybe a u-boot specific prop could be
added to the config node, similar to sysreset-gpio,
see doc/device-tree-bindings/config.txt.

Regards,
Jonas

> 
> Greetings,
> 
> -- Sebastian
> 
>>
>> Regards,
>> Jonas
>>
>>> +{
>>> +   struct udevice *dev;
>>> +   int ret;
>>> +
>>> +   /*
>>> +* This will do early USB PD (power deliver) negotiation, which must
>>> +* happen within 5 seconds after the USB-C connector has plugged in
>>> +* according to the specification. It takes almost 5 seconds to go
>>> +* through the bootchain on Rock 5B and jump to the operating system.
>>> +* When the Linux initializes the fusb302 usually 20-30 seconds have
>>> +* gone since the device has been plugged, which is far too late.
>>> +*
>>> +* The USB PD power source reacts with a hard reset, which d

Re: [PATCH v2 1/5] arm64: dts: rockchip: Add Radxa ZERO 3W/3E

[Kever Yang]

On 2024/8/3 06:12, Jonas Karlman wrote:

The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

The ZERO 3W and ZERO 3E are basically the same size and model, but
differ only in storage and network interfaces.

- eMMC (3W)
- SD-card (both)
- Ethernet (3E)
- WiFi/BT (3W)

Add initial support for eMMC, SD-card, Ethernet, HDMI and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521202810.1225636-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 1a5c8d307c83c808a32686ed51afb4bac2092d39 ]

(cherry picked from commit 1476c5882f8a47b6f0f895c6424dacf6334487ae)
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Add Signed-off-by tag
---
  .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 463 ++
  .../arm64/rockchip/rk3566-radxa-zero-3e.dts   |  51 ++
  .../arm64/rockchip/rk3566-radxa-zero-3w.dts   |  91 
  3 files changed, 605 insertions(+)
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
  create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
new file mode 100644
index ..623d5939d194
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   aliases {
+   mmc0 = &sdmmc0;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "d";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&user_led2>;
+
+   led-green {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vcc_1v8: regulator-1v8-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca_1v8: regulator-1v8-vcca {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca1v8_image: regulator-1v8-vcca-image {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca1v8_image";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcc_3v3: regulator-3v3-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_3v3";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc3v3_sys>;
+   };
+
+   vcc_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+&combphy1 {
+   status = "okay";
+};
+
+&cpu0 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+   mali-supply = <&vdd_gpu_npu>;
+   status = "okay";
+};
+
+&hdmi {
+   avdd-0v9-supply = <&vdda_0v9>;
+   avdd-1v8-supply = <&vcca1v8_image>;
+   status = "okay";
+};
+
+&hdmi_in {
+   hdmi_in_vp0: endpoint {
+   remote-endpoint = <&vp0_out_hdmi>;
+   };
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-en

Re: [PATCH v2 2/5] arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

[Kever Yang]

On 2024/8/3 06:12, Jonas Karlman wrote:

From: FUKAUMI Naoki 

align with other Radxa products.

- mmc0 is eMMC
- mmc1 is microSD

for ZERO 3E, there is no eMMC, but aliases should start at 0, so mmc0
is microSD as exception.

Fixes: 1a5c8d307c83 ("arm64: dts: rockchip: Add Radxa ZERO 3W/3E")
Signed-off-by: FUKAUMI Naoki 

Changes in v3:
- fix syntax error in rk3566-radxa-zero-3e.dts
Changes in v2:
- microSD is mmc0 instead of mmc1 for ZERO 3E

Link: https://lore.kernel.org/r/20240620224435.2752-1-na...@radxa.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: 060c1950037e4c54ca4d8186a8f46269e35db901 ]

(cherry picked from commit 8324bc7493e4088013c62bc41f49d6d181575493)
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Add Signed-off-by tag
---
  dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi | 4 
  dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts | 1 +
  dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts | 3 ++-
  3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 623d5939d194..081be841b286 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -6,10 +6,6 @@
  #include "rk3566.dtsi"
  
  / {

-   aliases {
-   mmc0 = &sdmmc0;
-   };
-
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
index e166d66990b9..4a830eb09f0b 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
@@ -10,6 +10,7 @@
  
  	aliases {

ethernet0 = &gmac1;
+   mmc0 = &sdmmc0;
};
  };
  
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

index 9bf4f464915f..f92475c59deb 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
@@ -9,7 +9,8 @@
compatible = "radxa,zero-3w", "rockchip,rk3566";
  
  	aliases {

-   mmc1 = &sdhci;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
mmc2 = &sdmmc1;
};
  

Re: [PATCH v2 3/5] arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

[Kever Yang]

On 2024/8/3 06:12, Jonas Karlman wrote:

From: Trevor Woerner 

Add names to the pins of the general-purpose expansion header as given
in the Radxa documentation[1] following the conventions in the kernel[2]
to make it easier for users to correlate pins with functions when using
utilities such as 'gpioinfo'.

[1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface
[2] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

Signed-off-by: Trevor Woerner 
Link: https://lore.kernel.org/r/20240620013301.33653-1-twoer...@gmail.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: f7c742cbe664ebdedc075945e75443683d1175f7 ]

(cherry picked from commit 8b26cf42ba0c74a9c86cebe591a9195f75151d97)
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Add Signed-off-by tag
---
  .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 72 +++
  1 file changed, 72 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 081be841b286..9cc7aa3298d0 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -105,6 +105,78 @@
cpu-supply = <&vdd_cpu>;
  };
  
+&gpio0 {

+   gpio-line-names =
+   /* GPIO0_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_D0 - D7 */
+   "pin-10 [GPIO0_D0]", "pin-08 [GPIO0_D1]", "",
+   "", "", "", "", "";
+};
+
+&gpio1 {
+   gpio-line-names =
+   /* GPIO1_A0 - A7 */
+   "pin-03 [GPIO1_A0]", "pin-05 [GPIO1_A1]", "",
+   "",  "pin-37 [GPIO1_A4]", "",
+   "",  "",
+   /* GPIO1_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio2 {
+   gpio-line-names =
+   /* GPIO2_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+   gpio-line-names =
+   /* GPIO3_A0 - A7 */
+   "",  "pin-11 [GPIO3_A1]", "pin-13 [GPIO3_A2]",
+   "pin-12 [GPIO3_A3]", "pin-35 [GPIO3_A4]", "pin-40 [GPIO3_A5]",
+   "pin-38 [GPIO3_A6]", "pin-36 [GPIO3_A7]",
+   /* GPIO3_B0 - B7 */
+   "pin-15 [GPIO3_B0]", "pin-16 [GPIO3_B1]", "pin-18 [GPIO3_B2]",
+   "pin-29 [GPIO3_B3]", "pin-31 [GPIO3_B4]", "",
+   "", "",
+   /* GPIO3_C0 - C7 */
+   "",  "pin-22 [GPIO3_C1]", "pin-32 [GPIO3_C2]",
+   "pin-33 [GPIO3_C3]", "pin-07 [GPIO3_C4]", "",
+   "", "",
+   /* GPIO3_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio4 {
+   gpio-line-names =
+   /* GPIO4_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO4_B0 - B7 */
+   "",  "",  "pin-27 [GPIO4_B2]",
+   "pin-28 [GPIO4_B3]", "", "", "", "",
+   /* GPIO4_C0 - C7 */
+   "",  "",  "pin-23 [GPIO4_C2]",
+   "pin-19 [GPIO4_C3]", "",  "pin-21 [GPIO4_C5]",
+   "pin-24 [GPIO4_C6]", "",
+   /* GPIO4_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
  &gpu {
mali-supply = <&vdd_gpu_npu>;
status = "okay";

Re: [PATCH v2 4/5] dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

[Kever Yang]

On 2024/8/3 06:12, Jonas Karlman wrote:

What model of Radxa ZERO 3W/3E board can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2:
- Drop depends on ADC and instead use $(SPL_TPL_) for adc-uclass.o
- Add depends on DM/SPL_DM to ADC/SPL_ADC
---
  drivers/Makefile | 2 +-
  drivers/adc/Kconfig  | 5 +
  drivers/adc/Makefile | 2 +-
  3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 9195dafd37e0..1acd94f3c17e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -1,5 +1,6 @@
  # SPDX-License-Identifier: GPL-2.0+
  
+obj-$(CONFIG_$(SPL_TPL_)ADC) += adc/

  obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
  obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
  obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
@@ -81,7 +82,6 @@ endif
  
  ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
  
-obj-y += adc/

  obj-y += ata/
  obj-$(CONFIG_DM_DEMO) += demo/
  obj-y += block/
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index c9cdbe6942de..37235f557a3c 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -1,5 +1,6 @@
  config ADC
bool "Enable ADC drivers using Driver Model"
+   depends on DM
help
  This enables ADC API for drivers, which allows driving ADC features
  by single and multi-channel methods for:
@@ -11,6 +12,10 @@ config ADC
  - support supply's phandle with auto-enable
  - supply polarity setting in fdt
  
+config SPL_ADC

+   bool "Enable ADC drivers using Driver Model in SPL"
+   depends on SPL_DM
+
  config ADC_EXYNOS
bool "Enable Exynos 54xx ADC driver"
depends on ADC
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index 5336c820973a..dca0b39c2e27 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -4,7 +4,7 @@
  # Przemyslaw Marczak 
  #
  
-obj-$(CONFIG_ADC) += adc-uclass.o

+obj-$(CONFIG_$(SPL_TPL_)ADC) += adc-uclass.o
  obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
  obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
  obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o

Re: [PATCH v2 5/5] board: rockchip: Add Radxa ZERO 3W/3E

[Kever Yang]

On 2024/8/3 06:12, Jonas Karlman wrote:

The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both board models.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
Tested-by: FUKAUMI Naoki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2:
- Add override for dr_mode in usb_host0_xhci node
   https://lore.kernel.org/linux-rockchip/20240802051508.498-1-na...@radxa.com/
- Collect t-b tag
---
  arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi | 15 
  arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi | 15 
  arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
  board/radxa/zero3-rk3566/Kconfig  | 12 +++
  board/radxa/zero3-rk3566/MAINTAINERS  |  6 ++
  board/radxa/zero3-rk3566/Makefile |  3 +
  board/radxa/zero3-rk3566/zero3-rk3566.c   | 59 +
  configs/radxa-zero-3-rk3566_defconfig | 85 +++
  doc/board/rockchip/rockchip.rst   |  1 +
  9 files changed, 202 insertions(+)
  create mode 100644 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
  create mode 100644 board/radxa/zero3-rk3566/Kconfig
  create mode 100644 board/radxa/zero3-rk3566/MAINTAINERS
  create mode 100644 board/radxa/zero3-rk3566/Makefile
  create mode 100644 board/radxa/zero3-rk3566/zero3-rk3566.c
  create mode 100644 configs/radxa-zero-3-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
new file mode 100644
index ..8af2581163be
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&usb_host0_xhci {
+   dr_mode = "otg";
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
new file mode 100644
index ..8af2581163be
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&usb_host0_xhci {
+   dr_mode = "otg";
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
b/arch/arm/mach-rockchip/rk3568/Kconfig
index 014ebf9f0ba7..0f32f243be4e 100644
--- a/arch/arm/mach-rockchip/rk3568/Kconfig
+++ b/arch/arm/mach-rockchip/rk3568/Kconfig
@@ -32,6 +32,11 @@ config TARGET_QUARTZ64_RK3566
help
  Pine64 Quartz64 single board computer with a RK3566 SoC.
  
+config TARGET_RADXA_ZERO_3_RK3566

+   bool "Radxa ZERO 3W/3E"
+   help
+ Radxa ZERO 3W/3E single board computers with a RK3566 SoC.
+
  endchoice
  
  config ROCKCHIP_BOOT_MODE_REG

@@ -54,5 +59,6 @@ source "board/anbernic/rgxx3_rk3566/Kconfig"
  source "board/hardkernel/odroid_m1/Kconfig"
  source "board/pine64/quartz64_rk3566/Kconfig"
  source "board/powkiddy/x55/Kconfig"
+source "board/radxa/zero3-rk3566/Kconfig"
  
  endif

diff --git a/board/radxa/zero3-rk3566/Kconfig b/board/radxa/zero3-rk3566/Kconfig
new file mode 100644
index ..7d46efc9c40f
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_RADXA_ZERO_3_RK3566
+
+config SYS_BOARD
+   default "zero3-rk3566"
+
+config SYS_VENDOR
+   default "radxa"
+
+config SYS_CONFIG_NAME
+   default "evb_rk3568"
+
+endif
diff --git a/board/radxa/zero3-rk3566/MAINTAINERS 
b/board/radxa/zero3-rk3566/MAINTAINERS
new file mode 100644
index ..e5a5d856113d
--- /dev/null
+++ b/board/radxa/zero3-rk3566/MAINTAINERS
@@ -0,0 +1,6 @@
+RADXA-ZERO-3-RK3566
+M: Jonas Karlman 
+S: Maintained
+F: board/radxa/zero3-rk3566
+F: configs/radxa-zero-3-rk3566_defconfig
+F: arch/arm/dts/rk3566-radxa-zero-3*
diff --git a/board/radxa/zero3-rk3566/Makefile 
b/board/radxa/zero3-rk3566/Makefile
new file mode 100644
index ..b28b58ed5d87
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += zero3-rk3566.o
diff --git a/board/radxa/zero3-rk3566/zero3-rk3566.c 
b/board/radxa/zero3-rk3566/zero3-rk3566.c
new file mode 100644
index ..cf30c4e38987
--- /dev/null
+++ b/board/radxa/zero3-rk3566/zero3-rk3566.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+
+#define HW_ID_CHANNEL  1
+
+str

Re: [PATCH v2 02/10] pinctrl: rockchip: Add a pin_to_bank() helper

[Kever Yang]

On 2024/8/3 06:56, Jonas Karlman wrote:

Add a pin_to_bank() helper that can locate a pin bank based on the pin
offset, to be used in get_gpio_mux() and gpio_request_enable() ops.

Reset ctrl->nr_pins to 0 so that pin_to_bank() can locate a bank after
the second probe in U-Boot proper.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch split from "pinctrl: rockchip: Add gpio_request_enable()
 ops" of "rockchip: Add gpio request() ops" series
---
  .../pinctrl/rockchip/pinctrl-rockchip-core.c   | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index f6af22501c36..894ff74aee98 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -176,6 +176,23 @@ static int rockchip_get_mux(struct rockchip_pin_bank 
*bank, int pin)
return ((val >> bit) & mask);
  }
  
+static struct rockchip_pin_bank *rockchip_pin_to_bank(struct udevice *dev,

+ unsigned int pin)
+{
+   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
+   struct rockchip_pin_ctrl *ctrl = priv->ctrl;
+   struct rockchip_pin_bank *bank = ctrl->pin_banks;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
+   if (pin >= bank->pin_base &&
+   pin < bank->pin_base + bank->nr_pins)
+   return bank;
+   }
+
+   return NULL;
+}
+
  static int rockchip_pinctrl_get_gpio_mux(struct udevice *dev, int banknum,
 int index)
  { struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
@@ -539,6 +556,7 @@ static struct rockchip_pin_ctrl 
*rockchip_pinctrl_get_soc_data(struct udevice *d
drv_pmu_offs = ctrl->pmu_drv_offset;
drv_grf_offs = ctrl->grf_drv_offset;
bank = ctrl->pin_banks;
+   ctrl->nr_pins = 0;
  
  	for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {

int bank_pins = 0;

Re: [PATCH v3 4/7] board: rock5b-rk3588: enable USB-C in operating system

[Jonas Karlman]

Hi Sebastian,

On 2024-08-03 18:09, Sebastian Reichel wrote:
> Hi Jonas,
> 
> On Fri, Aug 02, 2024 at 11:04:05PM GMT, Jonas Karlman wrote:
>> Hi Sebastian,
>>
>> On 2024-08-02 19:59, Sebastian Reichel wrote:
>>> Since older U-Boot releases do not negotiate USB PD, the kernel
>>> DT may not enable the USB-C controller by default to avoid a
>>> regression. The plan is to upstream it with 'status = "fail";'
>>> instead. U-Boot should then mark it as 'status = "okay";' if
>>> it negotiated USB PD. Currently existing upstream kernel DTs do
>>> not yet have the USB-C controller at all, so we ignore any
>>> failures.
>>
>> I do not really understand why you need to upstream it this way, there
>> are plenty of other rk3588 boards with fcs,fusb302 already having status
>> "okay" that possible are affected by same USB PD issue that ROCK 5B
>> have.
>>
>> I guess you want to try and protect users that upgrade kernel DT and
>> ignore upgrading to a newer U-Boot, use vendor U-Boot or any other
>> bootloader from having possible issues with those USB PD power supplies
>> that have issues?
> 
> Correct. Existing upstream U-Boot with new kernel would result in a
> boot loop. That's precisly why we need this U-Boot series. Since the
> Rock 5B is usually powered via USB-C and Radxa explicitly requests a
> USB-C PD power-supply almost everyone would be affected. IDK how
> other boards solve this considering U-Boot does not yet have a
> fusb302 driver. For me **all** of my power-supplies trigger a hard
> reset and thus a power-loss when booting a kernel with fusb302
> combined with an old U-Boot version not supporting fusb302.
> 
> -- Sebastian
> 
>>> Signed-off-by: Sebastian Reichel 
>>> ---
>>>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
>>> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> index 1c17ae93c76c..4e926ebf2cb0 100644
>>> --- a/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> @@ -3,6 +3,8 @@
>>>   * Copyright (c) 2023-2024 Collabora Ltd.
>>>   */
>>>  
>>> +#include 
>>> +#include 
>>>  #include 
>>>  
>>>  #ifdef CONFIG_MISC_INIT_R
>>> @@ -33,3 +35,12 @@ int misc_init_r(void)
>>> return 0;
>>>  }
>>>  #endif
>>> +
>>> +#ifdef CONFIG_OF_BOARD_SETUP
>>> +int ft_board_setup(void *blob, struct bd_info *bd)
>>> +{
>>> +   if (IS_ENABLED(CONFIG_MISC_INIT_R))
>>
>> It make very little sense to check for this, it is implied for almost
>> all Rockchip boards since it is used in rockchip board common code
>> to setup serial and Ethernet mac addresses env vars.

As noted, please drop this check, MISC_INIT_R is implied for almost all
Rockchip targets and has nothing to do with when status should change
for fcs,fusb302.

Regards,
Jonas

>>
>> Regards,
>> Jonas
>>
>>> +   fdt_status_okay_by_compatible(blob, "fcs,fusb302");
>>> +   return 0;
>>> +}
>>> +#endif
>>

Re: [PATCH v2 05/10] pinctrl: rockchip: Add gpio_request_enable() ops

[Kever Yang]

On 2024/8/3 06:56, Jonas Karlman wrote:

Implement gpio_request_enable() ops so that the gpio request() ops can
be implemented and a gpio requested pin automatically is pinmuxed for
gpio use, similar to Linux kernel.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch from "rockchip: Add gpio request() ops" series
---
  drivers/pinctrl/rockchip/pinctrl-rockchip-core.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index 345e0abdf5d1..e164af0d8f61 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -358,6 +358,18 @@ static int rockchip_set_mux(struct rockchip_pin_bank 
*bank, int pin, int mux)
return 0;
  }
  
+static int rockchip_pinctrl_gpio_request_enable(struct udevice *dev,

+   unsigned int selector)
+{
+   struct rockchip_pin_bank *bank;
+
+   bank = rockchip_pin_to_bank(dev, selector);
+   if (!bank)
+   return -EINVAL;
+
+   return rockchip_set_mux(bank, selector - bank->pin_base, RK_FUNC_GPIO);
+}
+
  static int rockchip_perpin_drv_list[DRV_TYPE_MAX][8] = {
{ 2, 4, 8, 12, -1, -1, -1, -1 },
{ 3, 6, 9, 12, -1, -1, -1, -1 },
@@ -608,6 +620,7 @@ const struct pinctrl_ops rockchip_pinctrl_ops = {
.set_state  = rockchip_pinctrl_set_state,
.get_gpio_mux   = rockchip_pinctrl_get_gpio_mux,
.get_pin_muxing = rockchip_pinctrl_get_pin_muxing,
+   .gpio_request_enable= rockchip_pinctrl_gpio_request_enable,
  };
  
  /* retrieve the soc specific data */

Re: [PATCH v2 08/10] gpio: rockchip: Add request() ops

[Kever Yang]

On 2024/8/3 06:56, Jonas Karlman wrote:

Add a request() ops that call pinctrl_gpio_request() when the required
gpio-ranges prop has been defined to signal pinctrl driver to use gpio
pinmux.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch from "rockchip: Add gpio request() ops" series
---
  drivers/gpio/rk_gpio.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 5972f7f8612d..65811dbc78d6 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -126,6 +126,15 @@ static int rockchip_gpio_get_function(struct udevice *dev, 
unsigned offset)
return (data & mask) ? GPIOF_OUTPUT : GPIOF_INPUT;
  }
  
+static int rockchip_gpio_request(struct udevice *dev, unsigned offset,

+const char *label)
+{
+   if (CONFIG_IS_ENABLED(PINCTRL) && dev_read_bool(dev, "gpio-ranges"))
+   return pinctrl_gpio_request(dev, offset, label);
+
+   return 0;
+}
+
  /* Simple SPL interface to GPIOs */
  #ifdef CONFIG_SPL_BUILD
  
@@ -229,6 +238,7 @@ static int rockchip_gpio_probe(struct udevice *dev)

  }
  
  static const struct dm_gpio_ops gpio_rockchip_ops = {

+   .request= rockchip_gpio_request,
.direction_input= rockchip_gpio_direction_input,
.direction_output   = rockchip_gpio_direction_output,
.get_value  = rockchip_gpio_get_value,

Re: [PATCH v2 09/10] rockchip: gpio: Add gpio-ranges props

[Kever Yang]

On 2024/8/3 06:56, Jonas Karlman wrote:

Add gpio-ranges props to supported SoCs based on the following Linux
patches:

ARM: dts: rockchip: add gpio-ranges property to gpio nodes
https://lore.kernel.org/all/26007385-81dc-9961-05d5-8b9a0969d...@gmail.com/

arm64: dts: rockchip: add gpio-ranges property to gpio nodes
https://lore.kernel.org/all/18c8c89a-9962-40f0-814f-81e2c420c...@gmail.com/

For RK3066 and RK3288 the gpio-ranges props is adjusted to match
https://lore.kernel.org/all/541b7633-af3b-4392-ac29-7ee1f2c6f...@kwiboo.se/

Re-enable gpio6 on RK3066 now that the pinctrl pin offset is used with
get_gpio_mux().

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: Collect r-b tag

Cc: Johan Jonker 
---
  arch/arm/dts/rk3036-u-boot.dtsi  | 12 
  arch/arm/dts/rk3066a-u-boot.dtsi |  3 +--
  arch/arm/dts/rk3128-u-boot.dtsi  | 16 
  arch/arm/dts/rk322x-u-boot.dtsi  | 16 
  arch/arm/dts/rk3288-u-boot.dtsi  | 33 
  arch/arm/dts/rk3308-u-boot.dtsi  | 20 +++
  arch/arm/dts/rk3328-u-boot.dtsi  | 13 +
  arch/arm/dts/rk3368-u-boot.dtsi  | 16 
  arch/arm/dts/rk3399-u-boot.dtsi  | 20 +++
  arch/arm/dts/rv1108-u-boot.dtsi  | 16 
  arch/arm/dts/rv1126-u-boot.dtsi  | 14 ++
  11 files changed, 177 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3036-u-boot.dtsi b/arch/arm/dts/rk3036-u-boot.dtsi
index 41ac054b81e8..3e788187f630 100644
--- a/arch/arm/dts/rk3036-u-boot.dtsi
+++ b/arch/arm/dts/rk3036-u-boot.dtsi
@@ -4,3 +4,15 @@
   */
  
  #include "rockchip-u-boot.dtsi"

+
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
diff --git a/arch/arm/dts/rk3066a-u-boot.dtsi b/arch/arm/dts/rk3066a-u-boot.dtsi
index 06f405ca2c5e..35b52d6fb7f3 100644
--- a/arch/arm/dts/rk3066a-u-boot.dtsi
+++ b/arch/arm/dts/rk3066a-u-boot.dtsi
@@ -24,6 +24,5 @@
  };
  
  &gpio6 {

-   status = "disabled";
+   gpio-ranges = <&pinctrl 0 160 16>;
  };
-
diff --git a/arch/arm/dts/rk3128-u-boot.dtsi b/arch/arm/dts/rk3128-u-boot.dtsi
index 6d1965e6b520..dd1208e7cf40 100644
--- a/arch/arm/dts/rk3128-u-boot.dtsi
+++ b/arch/arm/dts/rk3128-u-boot.dtsi
@@ -14,6 +14,22 @@
bootph-all;
  };
  
+&gpio0 {

+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
  &grf {
bootph-all;
  };
diff --git a/arch/arm/dts/rk322x-u-boot.dtsi b/arch/arm/dts/rk322x-u-boot.dtsi
index aea917544b1c..f0e2a1f95aa0 100644
--- a/arch/arm/dts/rk322x-u-boot.dtsi
+++ b/arch/arm/dts/rk322x-u-boot.dtsi
@@ -47,6 +47,22 @@
max-frequency = <15000>;
  };
  
+&gpio0 {

+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
  &grf {
bootph-all;
  };
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index a43d320ade7b..0f8053a8b690 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -95,8 +95,41 @@
clock-names = "clk_edp", "clk_edp_24m", "pclk_edp";
  };
  
+&gpio0 {

+   gpio-ranges = <&pinctrl 0 0 24>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 24 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 56 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 88 32>;
+};
+
+&gpio4 {
+   gpio-ranges = <&pinctrl 0 120 32>;
+};
+
+&gpio5 {
+   gpio-ranges = <&pinctrl 0 152 32>;
+};
+
+&gpio6 {
+   gpio-ranges = <&pinctrl 0 184 32>;
+};
+
  &gpio7 {
bootph-all;
+   gpio-ranges = <&pinctrl 0 216 32>;
+};
+
+&gpio8 {
+   gpio-ranges = <&pinctrl 0 248 16>;
  };
  
  &grf {

diff --git a/arch/arm/dts/rk3308-u-boot.dtsi b/arch/arm/dts/rk3308-u-boot.dtsi
index b7964e2756f3..c2d56b532f80 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -54,6 +54,26 @@
bootph-some-ram;
  };
  
+&gpio0 {

+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
+&gpio4 {
+   gpio-ranges = <&pinctrl 0 128 32>;
+};
+
  &grf {
bootph-all;
  };
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 0135bc08d491..3bc776146a82 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -57,6 +57,19 @@
  
  &gpio0 {

bootph-pre-ram;
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;

[PATCH] sf: Add lock info option to sf command list

[Venkatesh Yadav Abbarapu]

Many SPI flashes have status/OTP bit for TOP or BOTTOM selection
in the status register that can protect selected regions of
the SPI NOR.

Take this bit into consideration while locking the region.
The command "sf lockinfo" shows whether the flash is TOP or
BOTTOM protected, based on this info the "offset" is provided to
the "sf protect lock" command.

Versal> sf erase 0 10
SF: 1048576 bytes @ 0x0 Erased: OK
Versal>sf lockinfo
Flash is BOTTOM protected
Versal> sf protect lock 0 2
Versal> sf erase 0 2
ERROR: flash area is locked
Versal> sf protect unlock 0 2
Versal> sf erase 0 2
SF: 131072 bytes @ 0x0 Erased: OK

Signed-off-by: Venkatesh Yadav Abbarapu 
---
 cmd/sf.c   | 30 +-
 drivers/mtd/spi/spi-nor-core.c | 16 
 include/linux/mtd/spi-nor.h|  1 +
 include/spi.h  |  3 +++
 include/spi_flash.h|  8 
 5 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index f43a2e08b3..62afa91057 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -413,6 +413,30 @@ static int do_spi_protect(int argc, char *const argv[])
return ret == 0 ? 0 : 1;
 }
 
+static int do_spi_lock_info(int argc, char *const argv[])
+{
+   int ret;
+
+   if (argc != 1)
+   return CMD_RET_USAGE;
+
+   ret = spi_flash_lock_info(flash);
+   if (ret < 0) {
+   printf("Flash info is not set\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (ret == BOTTOM_PROTECT) {
+   printf("Flash is BOTTOM protected\n");
+   return CMD_RET_SUCCESS;
+   } else if (ret == TOP_PROTECT) {
+   printf("Flash is TOP protected\n");
+   return CMD_RET_SUCCESS;
+   }
+
+   return CMD_RET_FAILURE;
+}
+
 enum {
STAGE_ERASE,
STAGE_CHECK,
@@ -607,6 +631,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, 
int argc,
ret = do_spi_flash_erase(argc, argv);
else if (IS_ENABLED(CONFIG_SPI_FLASH_LOCK) && strcmp(cmd, "protect") == 
0)
ret = do_spi_protect(argc, argv);
+   else if (IS_ENABLED(CONFIG_SPI_FLASH_LOCK) && strcmp(cmd, "lockinfo") 
== 0)
+   ret = do_spi_lock_info(argc, argv);
else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test"))
ret = do_spi_flash_test(argc, argv);
else
@@ -632,7 +658,9 @@ U_BOOT_LONGHELP(sf,
" or to start of mtd 
`partition'\n"
 #ifdef CONFIG_SPI_FLASH_LOCK
"sf protect lock/unlock sector len  - protect/unprotect 'len' bytes 
starting\n"
-   " at address 'sector'"
+   " at address 'sector'\n"
+   "sf lockinfo- shows whether the flash 
locking is top or bottom\n"
+   " protected\n"
 #endif
 #ifdef CONFIG_CMD_SF_TEST
"\nsf test offset len   - run a very basic destructive test"
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index aea611fef5..2114be1e61 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1410,6 +1410,21 @@ static int stm_is_unlocked(struct spi_nor *nor, loff_t 
ofs, uint64_t len)
 
return stm_is_unlocked_sr(nor, ofs, len, status);
 }
+
+static bool stm_lock_info(struct spi_nor *nor)
+{
+   int status;
+
+   status = read_sr(nor);
+   if (status < 0)
+   return status;
+
+   if (status & SR_TB)
+   return BOTTOM_PROTECT;
+
+   return TOP_PROTECT;
+}
+
 #endif /* CONFIG_SPI_FLASH_STMICRO */
 #endif
 
@@ -4145,6 +4160,7 @@ int spi_nor_scan(struct spi_nor *nor)
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_unlocked = stm_is_unlocked;
+   nor->flash_lock_info = stm_lock_info;
}
 #endif
 
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index d1dbf3eadb..48d39a7052 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -580,6 +580,7 @@ struct spi_nor {
int (*quad_enable)(struct spi_nor *nor);
int (*octal_dtr_enable)(struct spi_nor *nor);
int (*ready)(struct spi_nor *nor);
+   bool (*flash_lock_info)(struct spi_nor *nor);
 
struct {
struct spi_mem_dirmap_desc *rdesc;
diff --git a/include/spi.h b/include/spi.h
index 7e38cc2a2a..46d27f7564 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -38,6 +38,9 @@
 
 #define SPI_DEFAULT_WORDLEN8
 
+#define BOTTOM_PROTECT 1
+#define TOP_PROTECT0
+
 /**
  * struct dm_spi_bus - SPI bus info
  *
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 10d19fd4b1..b8a6456fe4 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -202,4 +202,12 @@ static inline int sp

Re: [PATCH v2 10/10] rockchip: gpio: Add missing gpio aliases

[Kever Yang]

On 2024/8/3 06:56, Jonas Karlman wrote:

Add aliases for gpio controllers to soc u-boot dtsi files that are
missing aliases in soc dtsi files to ensure dev_seq() return the
expected number when a gpio controller is included in SPL.

Also drop the aliases from rk3288-u-boot.dtsi, they are already part of
rk3288.dtsi.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v2: New patch
---
  arch/arm/dts/px30-u-boot.dtsi| 4 
  arch/arm/dts/rk3066a-u-boot.dtsi | 7 +++
  arch/arm/dts/rk3288-u-boot.dtsi  | 9 -
  arch/arm/dts/rk3xxx-u-boot.dtsi  | 7 +++
  arch/arm/dts/rv1108-u-boot.dtsi  | 9 +
  arch/arm/dts/rv1126-u-boot.dtsi  | 8 
  6 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
index abc6b49e6663..3dc70d4e432b 100644
--- a/arch/arm/dts/px30-u-boot.dtsi
+++ b/arch/arm/dts/px30-u-boot.dtsi
@@ -7,6 +7,10 @@
  
  / {

aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
mmc0 = &emmc;
mmc1 = &sdmmc;
};
diff --git a/arch/arm/dts/rk3066a-u-boot.dtsi b/arch/arm/dts/rk3066a-u-boot.dtsi
index 35b52d6fb7f3..60d18d2daeac 100644
--- a/arch/arm/dts/rk3066a-u-boot.dtsi
+++ b/arch/arm/dts/rk3066a-u-boot.dtsi
@@ -3,6 +3,13 @@
  #include "rockchip-u-boot.dtsi"
  #include "rk3xxx-u-boot.dtsi"
  
+/ {

+   aliases {
+   gpio4 = &gpio4;
+   gpio6 = &gpio6;
+   };
+};
+
  &gpio0 {
gpio-ranges = <&pinctrl 0 0 32>;
  };
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 0f8053a8b690..379d9413adee 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -7,15 +7,6 @@
  
  / {

aliases {
-   gpio0 = &gpio0;
-   gpio1 = &gpio1;
-   gpio2 = &gpio2;
-   gpio3 = &gpio3;
-   gpio4 = &gpio4;
-   gpio5 = &gpio5;
-   gpio6 = &gpio6;
-   gpio7 = &gpio7;
-   gpio8 = &gpio8;
mmc0 = &emmc;
mmc1 = &sdmmc;
mmc2 = &sdio0;
diff --git a/arch/arm/dts/rk3xxx-u-boot.dtsi b/arch/arm/dts/rk3xxx-u-boot.dtsi
index 6af6a451ea78..097407ca72dc 100644
--- a/arch/arm/dts/rk3xxx-u-boot.dtsi
+++ b/arch/arm/dts/rk3xxx-u-boot.dtsi
@@ -1,6 +1,13 @@
  // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  
  / {

+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   };
+
noc: syscon@10128000 {
compatible = "rockchip,rk3188-noc", "syscon";
reg = <0x10128000 0x2000>;
diff --git a/arch/arm/dts/rv1108-u-boot.dtsi b/arch/arm/dts/rv1108-u-boot.dtsi
index f772d618bd1d..58711e8b2f8a 100644
--- a/arch/arm/dts/rv1108-u-boot.dtsi
+++ b/arch/arm/dts/rv1108-u-boot.dtsi
@@ -5,6 +5,15 @@
  
  #include "rockchip-u-boot.dtsi"
  
+/ {

+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   };
+};
+
  &gpio0 {
gpio-ranges = <&pinctrl 0 0 32>;
  };
diff --git a/arch/arm/dts/rv1126-u-boot.dtsi b/arch/arm/dts/rv1126-u-boot.dtsi
index 3e6df1e433db..05b5f5260dd5 100644
--- a/arch/arm/dts/rv1126-u-boot.dtsi
+++ b/arch/arm/dts/rv1126-u-boot.dtsi
@@ -6,6 +6,14 @@
  #include "rockchip-u-boot.dtsi"
  
  / {

+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   gpio4 = &gpio4;
+   };
+
chosen {
u-boot,spl-boot-order = \
"same-as-spl", &emmc, &sdmmc;

Re: [PATCH] rockchip: rk3568-nanopi-r5: Disable SPL_DM_WARN Kconfig option

[Kever Yang]

On 2024/8/3 07:48, Jonas Karlman wrote:

With the commit 6afdb1585112 ("dm: core: migrate debug() messages to use
dm_warn") use of DM_WARN/SPL_DM_WARN print a lot of debug messages.

Disable the SPL_DM_WARN Kconfig option to remove verbose logging and
restore normal serial console output during boot.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/nanopi-r5c-rk3568_defconfig | 1 -
  configs/nanopi-r5s-rk3568_defconfig | 1 -
  2 files changed, 2 deletions(-)

diff --git a/configs/nanopi-r5c-rk3568_defconfig 
b/configs/nanopi-r5c-rk3568_defconfig
index 4a6c320faf5c..8e30093ed9dc 100644
--- a/configs/nanopi-r5c-rk3568_defconfig
+++ b/configs/nanopi-r5c-rk3568_defconfig
@@ -35,7 +35,6 @@ CONFIG_CMD_REGULATOR=y
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_OF_LIVE=y
  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
-CONFIG_SPL_DM_WARN=y
  CONFIG_SPL_DM_SEQ_ALIAS=y
  CONFIG_SPL_REGMAP=y
  CONFIG_SPL_SYSCON=y
diff --git a/configs/nanopi-r5s-rk3568_defconfig 
b/configs/nanopi-r5s-rk3568_defconfig
index 7ab12e619acf..e1865b2e1714 100644
--- a/configs/nanopi-r5s-rk3568_defconfig
+++ b/configs/nanopi-r5s-rk3568_defconfig
@@ -35,7 +35,6 @@ CONFIG_CMD_REGULATOR=y
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_OF_LIVE=y
  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
-CONFIG_SPL_DM_WARN=y
  CONFIG_SPL_DM_SEQ_ALIAS=y
  CONFIG_SPL_REGMAP=y
  CONFIG_SPL_SYSCON=y

Re: [PATCH v6] board: rockchip: add Radxa ROCK 3 Model C

[Kever Yang]

On 2024/8/9 03:37, Maxim Moskalets wrote:

From: Maxim Moskalets 

Based on rock-3a-rk3568_defconfig.
Tested on v1.31 revision.

Board Specifications:
- Rockchip RK3566
- 1/2/4GB LPDDR4 2112MT/s
- eMMC socket
- uSD card slot
- M.2 2230 Connector
- GbE LAN with POE
- 3.5mm jack with mic
- HDMI 2.0, MIPI DSI/CSI
- USB 3.0 Host, USB 2.0 Host/OTG
- 40-pin GPIO expansion ports

Signed-off-by: Maxim Moskalets 
Suggested-by: Jonas Karlman 
Reviewed-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
v6:
update dts to turn LED up in U-Boot
v5:
fixed board info
v4:
fixed typo in commit-msg
moved maintainers record to file for rk3568 boards
renamed from ROCK 3 Model C to ROCK3C
v3:
add suggested by Jonas Karlman  in

https://lore.kernel.org/all/bbb81dd1-e318-423d-8258-db7556ce6...@kwiboo.se/
v2:
rebase to updated upstream dts
---
  arch/arm/dts/rk3566-rock-3c-u-boot.dtsi | 18 +
  board/rockchip/evb_rk3568/MAINTAINERS   |  7 ++
  configs/rock-3c-rk3566_defconfig| 97 +
  doc/board/rockchip/rockchip.rst |  1 +
  4 files changed, 123 insertions(+)
  create mode 100644 arch/arm/dts/rk3566-rock-3c-u-boot.dtsi
  create mode 100644 configs/rock-3c-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-rock-3c-u-boot.dtsi 
b/arch/arm/dts/rk3566-rock-3c-u-boot.dtsi
new file mode 100644
index 000..f4124aa48fc
--- /dev/null
+++ b/arch/arm/dts/rk3566-rock-3c-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
+
+/ {
+   leds {
+   led-0 {
+   default-state = "on";
+   };
+   };
+};
diff --git a/board/rockchip/evb_rk3568/MAINTAINERS 
b/board/rockchip/evb_rk3568/MAINTAINERS
index e5b0986ead9..ba4884db8e1 100644
--- a/board/rockchip/evb_rk3568/MAINTAINERS
+++ b/board/rockchip/evb_rk3568/MAINTAINERS
@@ -69,3 +69,10 @@ S:   Maintained
  F:configs/rock-3a-rk3568_defconfig
  F:arch/arm/dts/rk3568-rock-3a.dts
  F:arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
+
+ROCK-3C
+M: Jonas Karlman 
+M: Maxim Moskalets 
+S: Maintained
+F: arch/arm/dts/rk3566-rock-3c-u-boot.dtsi
+F: configs/rock-3c-rk3566_defconfig
diff --git a/configs/rock-3c-rk3566_defconfig b/configs/rock-3c-rk3566_defconfig
new file mode 100644
index 000..f44b202c8c3
--- /dev/null
+++ b/configs/rock-3c-rk3566_defconfig
@@ -0,0 +1,97 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3566-rock-3c"
+CONFIG_ROCKCHIP_RK3568=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xFE66
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3566-rock-3c.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_POWEROFF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=4
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_NVME_PCI=y
+CONFIG_PCIE_DW_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_SPL_RAM=y
+CONFIG_SCSI=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SFC=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERI

Re: [PATCH] arm64: dts: rockchip: change spi-max-frequency for Radxa ROCK 3C

[Kever Yang]

On 2024/8/5 10:26, FUKAUMI Naoki wrote:

SPI NOR flash chip may vary, so use safe(lowest) spi-max-frequency.

Signed-off-by: FUKAUMI Naoki 
Link: https://lore.kernel.org/r/20240623023329.1044-3-na...@radxa.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: 06f6dd4d607766a527e37529f2f3f90dd1464293 ]

(cherry picked from commit dd40945a1d0e28ae6eaf9da04f8e2dcebf8233ea)

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  dts/upstream/src/arm64/rockchip/rk3566-rock-3c.dts | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-rock-3c.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-rock-3c.dts
index b242409d378..f2cc086e500 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-rock-3c.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-rock-3c.dts
@@ -633,7 +633,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0x0>;
-   spi-max-frequency = <12000>;
+   spi-max-frequency = <10400>;
spi-rx-bus-width = <4>;
spi-tx-bus-width = <1>;
};

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz,
> 
> On Thu, 8 Aug 2024 at 03:06, Lukasz Majewski  wrote:
> >
> > Dear Community
> >
> > I'd like to ask about one issue with generation of symbol offsets in
> > binman [1].
> >
> > In my case the CONFIG_FSPI_CONF_HEADER is defined.
> >
> > Problem is with generated symbols [2] to point into
> > ddr-1d-imem-fw/ddr-1d-dmem-fw/ddr-2d-imem-fw/ddr-2d-dmem-fw.
> >
> > It looks like only symbols have extra offset of 0x1000 (the same as
> > the first section introduces) - binaries for training memory are
> > placed without this extra offset.
> >
> > On the other hand - before this change:
> > SHA1: 37e50627efacd8dae18b564e9d8886a033e181bc
> >
> > The u-boot-spl-ddr.bin was a separate binman "entry" (i.e. not
> > section)
> > - so e.g. ddr-1d-dmem-fw {} had proper offsets (as this binary was
> > also mangled into spl.bin with mkimage invocation).
> >
> >
> > Now the question - how to properly fix this issue?
> >
> > I've tried to add pad-before = <0x1000>; to ddr-1d-imem-fw property
> > hoping to "move" this binary itself by 0x1000. However with it the
> > symbol of ddr-1d-dmem-fw is moved up as well.
> >
> > Another option was to try alignment 'align-size' set to 0x1000 -
> > effect is the same as described above.
> >
> > In the documentation [3] - I've found that I could use
> > "ProcessEntryContents()" for tweaking, but this seems to be not
> > eligible (as all imx8mX boards, which are going to boot from fspi)
> > are affected.
> >
> > Maybe falling-back to 'multiple-images' [4] and generate the
> > u-boot-spl-ddr.bin in that way is a proper solution?
> >
> >
> > Last but not least - this problem is not present when one boots from
> > SD/eMMC as in this case the "fspi_conf_block" property is not
> > present and everything starts with 0x0 offset.
> >
> > Thanks in advance for your help.  
> 
> BTW we are waiting for tests for this etype...when those are in place
> it should provide a way to test the behaviour.
> 
> I see that Entry_nxp_imx8mimage.SetImagePos() adjusts the image-pos.
> Is that the symbol you are writing? Are you saying that the image_pos
> symbol that is written is incorrect?
> 

Yes, it is up by +0x1000 when compared to the real place where binaries
(like ddr_1d_imem_fw) are placed.

> Or are you using u-boot-spl-mkimage.signed.bin (i.e. without the 4KB
> header) in the first section.

No, HAB (signing) is disabled.

Instead I'm using the CONFIG_FSPI_CONF_HEADER from [1]. It adds FSPI
(QSPI) specific header with 0x1000 size.

> 
> The image_pos is an absolute image position, so it doesn't matter what
> sections are written out as files. The image_pos will be the same
> regardless.

To have the board booting again - I do need to perform:

 imem_start -= 0x1000;
 dmem_start -= 0x1000;

added at [5].

> 
> Why are u-boot-spl-mkimage.signed.bin and u-boot-fit.signed.bin
> written out? Aren't they just intermediate images, not useful for
> flashing to the board? If not, why is the FSPI conf block before them?
> 

As stated above - I'm not using HAB so those are not created.

The FSPI block is required to boot the device with QSPI - it holds meta
data to configure the memory itself.

> There is a 'skip-at-start' property which might be useful here, so
> long as I understand the above correctly.

Ok - I will try it.

Thanks for your help :-)

> 
> Regards,
> Simon
> 
> 
> >
> >
> > Links:
> >
> > [1] -
> >  
> > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mm-u-boot.dtsi?ref_type=heads#L49
> >
> > [2] -
> > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/ddr/imx/phy/helper.c#L27
> >
> > [3] -
> > https://github.com/ARM-software/u-boot/blob/master/tools/binman/README#L526
> >
> > [4] -
> > https://github.com/ARM-software/u-boot/blob/master/tools/binman/README#L371
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,  Managing Director: Erika Unter
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lu...@denx.de  

Links:

[5] -
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/ddr/imx/phy/helper.c#L87


Best regards,

Lukasz Majewski

--

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


pgp4AIODsaLtz.pgp
Description: OpenPGP digital signature

[PATCH v2 2/3] compiler: Ensure __builtin_*_overflow() support

[Richard Weinberger]

Both gcc and clang support this for a long time.
Make sure the feature is present.

Signed-off-by: Richard Weinberger 
---
 include/linux/compiler_types.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1a3060117f..8b6ce9c11c 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -70,6 +70,13 @@ extern void __chk_io_ptr(const volatile void __iomem *);
 #error "Unknown compiler"
 #endif
 
+/*
+ * At least gcc 5.1 or clang 8 are needed.
+ */
+#ifndef COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW
+#error Unsupported compiler
+#endif
+
 /*
  * Some architectures need to provide custom definitions of macros provided
  * by linux/compiler-*.h, and can do so using asm/compiler.h. We include that
-- 
2.35.3

[PATCH v2 1/3] ext4: Fix integer overflow in ext4fs_read_symlink()

[Richard Weinberger]

While zalloc() takes a size_t type, adding 1 to the le32 variable
will overflow.
A carefully crafted ext4 filesystem can exhibit an inode size of 0x
and as consequence zalloc() will do a zero allocation.

Later in the function the inode size is again used for copying data.
So an attacker can overwrite memory.

Avoid the overflow by using the __builtin_add_overflow() helper.

Signed-off-by: Richard Weinberger 
---
 fs/ext4/ext4_common.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 52152a2295..36999b608f 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2181,13 +2181,18 @@ static char *ext4fs_read_symlink(struct ext2fs_node 
*node)
struct ext2fs_node *diro = node;
int status;
loff_t actread;
+   size_t alloc_size;
 
if (!diro->inode_read) {
status = ext4fs_read_inode(diro->data, diro->ino, &diro->inode);
if (status == 0)
return NULL;
}
-   symlink = zalloc(le32_to_cpu(diro->inode.size) + 1);
+
+   if (__builtin_add_overflow(le32_to_cpu(diro->inode.size), 1, 
&alloc_size))
+   return NULL;
+
+   symlink = zalloc(alloc_size);
if (!symlink)
return NULL;
 
-- 
2.35.3

[PATCH v2 3/3] ext4: Fix zalloc()

[Richard Weinberger]

Currently, zalloc() calls uncondtionally memset(),
if the allocation failes, memset() will write to a null pointer.

Fix by using kzalloc().

Signed-off-by: Richard Weinberger 
---
 fs/ext4/ext4_common.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/ext4_common.h b/fs/ext4/ext4_common.h
index 84500e990a..346752092b 100644
--- a/fs/ext4/ext4_common.h
+++ b/fs/ext4/ext4_common.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #if defined(CONFIG_EXT4_WRITE)
 #include "ext4_journal.h"
@@ -43,9 +44,7 @@
 
 static inline void *zalloc(size_t size)
 {
-   void *p = memalign(ARCH_DMA_MINALIGN, size);
-   memset(p, 0, size);
-   return p;
+   return kzalloc(size, 0);
 }
 
 int ext4fs_read_inode(struct ext2_data *data, int ino,
-- 
2.35.3

Re: [PATCH] configs: rockchip: enable "ums" command for Radxa ROCK 5B

[Kever Yang]

On 2024/8/6 11:47, FUKAUMI Naoki wrote:

USB Type-C port is configured as "peripheral" port. so enable "ums"
command to use as USB Mass Storage device.
("rockusb" command is already enabled and working)

Signed-off-by: FUKAUMI Naoki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/rock5b-rk3588_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index fc118cea7ba..80a2f2fed58 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -39,6 +39,7 @@ CONFIG_CMD_MMC=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_USB=y
  CONFIG_CMD_ROCKUSB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
  # CONFIG_CMD_SETEXPR is not set
  CONFIG_CMD_REGULATOR=y
  # CONFIG_SPL_DOS_PARTITION is not set

Re: [PATCH v2 3/3] ext4: Fix zalloc()

[Heinrich Schuchardt]

On 8/9/24 11:54, Richard Weinberger wrote:

Currently, zalloc() calls uncondtionally memset(),
if the allocation failes, memset() will write to a null pointer.

Fix by using kzalloc().

Signed-off-by: Richard Weinberger 


Reviewed-by: Heinrich Schuchardt 


---
  fs/ext4/ext4_common.h | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/ext4_common.h b/fs/ext4/ext4_common.h
index 84500e990a..346752092b 100644
--- a/fs/ext4/ext4_common.h
+++ b/fs/ext4/ext4_common.h
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #if defined(CONFIG_EXT4_WRITE)
  #include "ext4_journal.h"
@@ -43,9 +44,7 @@

  static inline void *zalloc(size_t size)
  {
-   void *p = memalign(ARCH_DMA_MINALIGN, size);
-   memset(p, 0, size);
-   return p;
+   return kzalloc(size, 0);
  }

  int ext4fs_read_inode(struct ext2_data *data, int ino,

Re: [PATCH v8 02/23] net: wget: removed unused function wget_success()

[Ilias Apalodimas]

On Wed, 7 Aug 2024 at 20:12, Jerome Forissier
 wrote:
>
> wget_success() is used nowhere so remove it.
>
> Signed-off-by: Jerome Forissier 
> ---
>  net/wget.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/net/wget.c b/net/wget.c
> index f1dd7abeff6..0e4dc5159d0 100644
> --- a/net/wget.c
> +++ b/net/wget.c
> @@ -199,13 +199,6 @@ void wget_fail(char *error_message, unsigned int 
> tcp_seq_num,
> wget_send(action, tcp_seq_num, tcp_ack_num, 0);
>  }
>
> -void wget_success(u8 action, unsigned int tcp_seq_num,
> - unsigned int tcp_ack_num, int len, int packets)
> -{
> -   printf("Packets received %d, Transfer Successful\n", packets);
> -   wget_send(action, tcp_seq_num, tcp_ack_num, len);
> -}
> -
>  /*
>   * Interfaces of U-BOOT
>   */
> --
> 2.40.1
>

Reviewed-by: Ilias Apalodimas 

Re: [PATCH] arm: dts: rockchip: fix dts for Radxa ROCK 4C+

[FUKAUMI Naoki]

Hi,

On 8/9/24 18:16, Kever Yang wrote:


On 2024/8/9 06:19, FUKAUMI Naoki wrote:

Radxa ROCK Pi 4 series and Radxa ROCK 4C+ are not compatible.


A little bit more detail about why not compatible?

The eMMC is different?


I should say "ROCK Pi 4 series and ROCK 4C+ cannot share dts file."

$ grep rk3399-rock-pi-4.dtsi dts/upstream/src/arm64/rockchip/*
dts/upstream/src/arm64/rockchip/rk3399-rock-4se.dts:#include 
"rk3399-rock-pi-4.dtsi"
dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4a-plus.dts:#include 
"rk3399-rock-pi-4.dtsi"
dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4a.dts:#include 
"rk3399-rock-pi-4.dtsi"
dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4b-plus.dts:#include 
"rk3399-rock-pi-4.dtsi"
dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4b.dts:#include 
"rk3399-rock-pi-4.dtsi"
dts/upstream/src/arm64/rockchip/rk3399-rock-pi-4c.dts:#include 
"rk3399-rock-pi-4.dtsi"


4C+ is different board.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.


Thanks,

- Kever


add
rk3399-rock-pi-4-u-boot.dtsi contents and remove dependency of it.

no functional change is intended.

Fixes: 71a95e2efd30 ("arm: dts: rockchip: add Radxa ROCK 4C+")
Suggested-by: Dragan Simic 
Signed-off-by: FUKAUMI Naoki 
---
  arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi 
b/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi

index 5ec15a845c1..50dae5cb5ef 100644
--- a/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rock-4c-plus-u-boot.dtsi
@@ -1,8 +1,10 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// SPDX-License-Identifier: GPL-2.0+
  /*
+ * Copyright (C) 2019 Jagan Teki 
   * Copyright (c) 2023 Radxa Limited
   */
-#include "rk3399-rock-pi-4-u-boot.dtsi"
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
  &pcfg_pull_none_18ma {
  bootph-pre-ram;
@@ -14,6 +16,12 @@
  bootph-some-ram;
  };
+&sdhci {
+    cap-mmc-highspeed;
+    mmc-ddr-1_8v;
+    mmc-hs200-1_8v;
+};
+
  &spi1 {
  status = "okay";
@@ -25,3 +33,7 @@
  spi-max-frequency = <1000>;
  };
  };
+
+&vdd_log {
+    regulator-init-microvolt = <95>;
+};

Re: [PATCH v8 03/23] net: wget: allow EFI boot

[Ilias Apalodimas]

On Wed, 7 Aug 2024 at 20:12, Jerome Forissier
 wrote:
>
> wget followed by bootefi currently fails as follows:
>
>  U-Boot> wget 20 192.168.0.30:helloworld.efi
>  Waiting for Ethernet connection... done.
>  HTTP/1.0 200 OK
>  Packets received 13, Transfer Successful
>  Bytes transferred = 12720 (31b0 hex)
>  U-Boot> bootefi 20
>  No UEFI binary known at 20
>  U-Boot>
>
> Fix the problem by adding the missing efi_set_bootdev() call.
>
> Signed-off-by: Jerome Forissier 
> ---
>  net/wget.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/wget.c b/net/wget.c
> index 0e4dc5159d0..cf7681a4e79 100644
> --- a/net/wget.c
> +++ b/net/wget.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -429,6 +430,9 @@ static void wget_handler(uchar *pkt, u16 dport,
> case WGET_TRANSFERRED:
> printf("Packets received %d, Transfer Successful\n", packets);
> net_set_state(wget_loop_state);
> +   efi_set_bootdev("Net", "", image_url,
> +   map_sysmem(image_load_addr, 0),
> +   net_boot_file_size);

Don't you need an unmap_sysmem() once this completes?

Thanks
/Ilias
> break;
> }
>  }
> --
> 2.40.1
>

[PATCH 1/1] tools: fix signature of toc0_verify_cert_item()

[Heinrich Schuchardt]

Avoid a build warning with GCC 14.2

tools/sunxi_toc0.c: In function ‘toc0_verify_cert_item’:
tools/sunxi_toc0.c:447:12: warning: ‘nonnull’ argument ‘digest’
compared to NULL [-Wnonnull-compare]
  447 | if (digest && memcmp(&extension->digest, digest, 
SHA256_DIGEST_LENGTH)) {
  |^

Use a pointer instead of an array to signal that the argument might be
NULL.

Signed-off-by: Heinrich Schuchardt 
---
 tools/sunxi_toc0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/sunxi_toc0.c b/tools/sunxi_toc0.c
index 292649fe90f..545c3771853 100644
--- a/tools/sunxi_toc0.c
+++ b/tools/sunxi_toc0.c
@@ -412,7 +412,7 @@ err:
  * This function is only expected to work with images created by mkimage.
  */
 static int toc0_verify_cert_item(const uint8_t *buf, uint32_t len, RSA *fw_key,
-uint8_t digest[static SHA256_DIGEST_LENGTH])
+uint8_t *digest)
 {
const struct toc0_cert_item *cert_item = (const void *)buf;
uint8_t cert_digest[SHA256_DIGEST_LENGTH];
-- 
2.45.2

Re: [PATCH v2 4/4] board: rockchip: Add Radxa ROCK 5 ITX

[Philipp Tomsich]

On Fri, 2 Aug 2024 at 23:00, Heiko Stuebner  wrote:
>
> The Rock 5 ITX is board in ITX form factor using the RK358 SoC

type "is a board"
typo: "RK3588"

> It can be powered either by 12V, ATX power-supply or PoE.
>
> Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot,
> 2*2.5Gb PCIe-connected Ethernet NICs.
>
> Display options are 2*HDMI, DP via USB-c, eDP + 2*DSI via PCB connectors.
>
> USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel
> connector.
>
> Schematics for the board can be found on
> - https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf
> - https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf
>
> The naming scheme with the dashes follows Dragan's comment on the mainline
> devicetree commit:
> "the name of this board deviates from the standard Radxa naming scheme,
>  which is something like "ROCK " thus, "rock-5a" is
>  fine, but it should be "rock-5-itx", simply because there's a space
>  between "5" and "ITX" in "ROCK 5 ITX"
>
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi |  22 
>  arch/arm/mach-rockchip/rk3588/Kconfig  |  29 ++
>  board/radxa/rock-5-itx-rk3588/Kconfig  |  12 +++
>  board/radxa/rock-5-itx-rk3588/MAINTAINERS  |   8 ++
>  configs/rock-5-itx-rk3588_defconfig| 111 +
>  doc/board/rockchip/rockchip.rst|   1 +
>  include/configs/rock-5-itx-rk3588.h|  15 +++
>  7 files changed, 198 insertions(+)
>  create mode 100644 arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
>  create mode 100644 board/radxa/rock-5-itx-rk3588/Kconfig
>  create mode 100644 board/radxa/rock-5-itx-rk3588/MAINTAINERS
>  create mode 100644 configs/rock-5-itx-rk3588_defconfig
>  create mode 100644 include/configs/rock-5-itx-rk3588.h
>
> diff --git a/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi 
> b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> new file mode 100644
> index 000..1e5c2674e49
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Collabora Ltd.
> + */
> +
> +#include "rk3588-u-boot.dtsi"
> +
> +&fspim2_pins {
> +   bootph-pre-ram;
> +   bootph-some-ram;
> +};
> +
> +&sfc {
> +   flash@0 {
> +   bootph-pre-ram;
> +   bootph-some-ram;
> +   };
> +};
> +
> +&vcc3v3_mkey {
> +   regulator-always-on;
> +};
> diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
> b/arch/arm/mach-rockchip/rk3588/Kconfig
> index e751d64e1a1..0dcf2249fb4 100644
> --- a/arch/arm/mach-rockchip/rk3588/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3588/Kconfig
> @@ -185,6 +185,34 @@ config TARGET_ROCK5B_RK3588
>   USB PD over USB Type-C
>   Size: 100mm x 72mm (Pico-ITX form factor)
>
> +config TARGET_ROCK_5_ITX_RK3588
> +   bool "Radxa ROCK-5-ITX RK3588 board"
> +   select BOARD_LATE_INIT
> +   help
> + Radxa ROCK-5-ITX is a Rockchip RK3588 based SBC (Single Board
> + Computer) by Radxa in the ITX formfactor.
> +
> + There are variants depending on the DRAM size : from 4G up to 32G.
> +
> + Specification:
> +
> + Rockchip Rk3588 SoC
> + 4x ARM Cortex-A76, 4x ARM Cortex-A55
> + 4/8/16/24/32GB memory LPDDR5
> + Mali G610MC4 GPU
> + 2x MIPI CSI 2 multiple lanes connector
> + eMMC
> + uSD slot (up to 128GB)
> + M.2 M-key and M.2 E-key connector
> + 4x SATA
> + 2x USB 2.0 + 4x USB 3.0 Type-A, 2x USB 2.0 Panel, 1x USB 3.0 Type-C
> + 2x HDMI 2.1 output, 1x HDMI input
> + DP via Type-C
> + 2x DSI via PCB connector
> + 2x 2.5 Gbps Ethernet port
> + Front-panel connectors for audio and case-power, -leds
> + Powered by either 12V, ATX power-supply or PoE
> +
>  config TARGET_SIGE7_RK3588
> bool "ArmSoM Sige7 RK3588 board"
> select BOARD_LATE_INIT
> @@ -319,6 +347,7 @@ source "board/pine64/quartzpro64-rk3588/Kconfig"
>  source "board/turing/turing-rk1-rk3588/Kconfig"
>  source "board/radxa/rock5a-rk3588s/Kconfig"
>  source "board/radxa/rock5b-rk3588/Kconfig"
> +source "board/radxa/rock-5-itx-rk3588/Kconfig"
>  source "board/rockchip/evb_rk3588/Kconfig"
>  source "board/rockchip/toybrick_rk3588/Kconfig"
>  source "board/theobroma-systems/jaguar_rk3588/Kconfig"
> diff --git a/board/radxa/rock-5-itx-rk3588/Kconfig 
> b/board/radxa/rock-5-itx-rk3588/Kconfig
> new file mode 100644
> index 000..f7a7666d531
> --- /dev/null
> +++ b/board/radxa/rock-5-itx-rk3588/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_ROCK_5_ITX_RK3588
> +
> +config SYS_BOARD
> +   default "rock-5-itx-rk3588"
> +
> +config SYS_VENDOR
> +   default "radxa"
> +
> +config SYS_CONFIG_NAME
> +   default "rock-5-itx-rk3588"
> +
> +endif
> diff --git a/board/radxa/rock-5-itx-rk3588/MAINTAINERS 
> b/board/radxa/rock-5-itx-rk3588/MAIN

Re: [PATCH] mtd: nand: raw: atmel: remove unnecessary return value

[Alexander Dahl]

Hello Marcus,

Am Fri, Aug 09, 2024 at 02:15:43PM +0200 schrieb Marcus Folkesson:
> The condition 'ret' is always true as it is never set to other than
> -EIO.

Technically, you're right.

I quickly compared with the same driver in Linux.  That has some
additional lines for DMA transfers which probably got removed when
porting the driver.

Does the code before your patch throw compiler warnings?  If not, I
would keep it as is.  The compiler will probably optimize it away
anyway, and it would make future ports from Linux easier.

Greets
Alex

> 
> Remove 'ret' and the condition for copy.
> 
> Signed-off-by: Marcus Folkesson 
> ---
> 
>  drivers/mtd/nand/raw/atmel/nand-controller.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index ee4ec6da58..00d7e177b9 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -568,12 +568,9 @@ static void atmel_nfc_copy_to_sram(struct nand_chip 
> *chip, const u8 *buf,
>   struct mtd_info *mtd = nand_to_mtd(chip);
>   struct atmel_nand *nand = to_atmel_nand(chip);
>   struct atmel_hsmc_nand_controller *nc;
> - int ret = -EIO;
>  
>   nc = to_hsmc_nand_controller(nand->controller);
> -
> - if (ret)
> - memcpy_toio(nc->sram.virt, buf, mtd->writesize);
> + memcpy_toio(nc->sram.virt, buf, mtd->writesize);
>  
>   if (oob_required)
>   memcpy_toio(nc->sram.virt + mtd->writesize, chip->oob_poi,
> @@ -586,12 +583,9 @@ static void atmel_nfc_copy_from_sram(struct nand_chip 
> *chip, u8 *buf,
>   struct mtd_info *mtd = nand_to_mtd(chip);
>   struct atmel_nand *nand = to_atmel_nand(chip);
>   struct atmel_hsmc_nand_controller *nc;
> - int ret = -EIO;
>  
>   nc = to_hsmc_nand_controller(nand->controller);
> -
> - if (ret)
> - memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
> + memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
>  
>   if (oob_required)
>   memcpy_fromio(chip->oob_poi, nc->sram.virt + mtd->writesize,
> -- 
> 2.45.1
> 

Re: [PATCH 1/1] tools: fix signature of toc0_verify_cert_item()

[Andre Przywara]

On Fri,  9 Aug 2024 13:22:16 +0200
Heinrich Schuchardt  wrote:

Hi Heinrich,

> Avoid a build warning with GCC 14.2
> 
> tools/sunxi_toc0.c: In function ‘toc0_verify_cert_item’:
> tools/sunxi_toc0.c:447:12: warning: ‘nonnull’ argument ‘digest’
> compared to NULL [-Wnonnull-compare]
>   447 | if (digest && memcmp(&extension->digest, digest, 
> SHA256_DIGEST_LENGTH)) {
>   |^
> 
> Use a pointer instead of an array to signal that the argument might be
> NULL.

Seung-Woo Kim sent a different patch for the same problem last week, and
Tom merged it earlier this week:
https://source.denx.de/u-boot/u-boot/-/commit/59fff91f2bea2215c7b16415b9a0e6714fac5573

Thanks for reporting anyways!

Cheers,
Andre

> 
> Signed-off-by: Heinrich Schuchardt 


> ---
>  tools/sunxi_toc0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/sunxi_toc0.c b/tools/sunxi_toc0.c
> index 292649fe90f..545c3771853 100644
> --- a/tools/sunxi_toc0.c
> +++ b/tools/sunxi_toc0.c
> @@ -412,7 +412,7 @@ err:
>   * This function is only expected to work with images created by mkimage.
>   */
>  static int toc0_verify_cert_item(const uint8_t *buf, uint32_t len, RSA 
> *fw_key,
> -  uint8_t digest[static SHA256_DIGEST_LENGTH])
> +  uint8_t *digest)
>  {
>   const struct toc0_cert_item *cert_item = (const void *)buf;
>   uint8_t cert_digest[SHA256_DIGEST_LENGTH];

Re: [PATCH] mtd: nand: raw: atmel: remove unnecessary return value

[Michael Nazzareno Trimarchi]

Hi all

On Fri, Aug 9, 2024 at 2:25 PM Alexander Dahl  wrote:
>
> Hello Marcus,
>
> Am Fri, Aug 09, 2024 at 02:15:43PM +0200 schrieb Marcus Folkesson:
> > The condition 'ret' is always true as it is never set to other than
> > -EIO.
>
> Technically, you're right.
>
> I quickly compared with the same driver in Linux.  That has some
> additional lines for DMA transfers which probably got removed when
> porting the driver.
>
> Does the code before your patch throw compiler warnings?  If not, I
> would keep it as is.  The compiler will probably optimize it away
> anyway, and it would make future ports from Linux easier.
>

I suggest to comment it because it will happen to other people to send a similar
patch

Michael

> Greets
> Alex
>
> >
> > Remove 'ret' and the condition for copy.
> >
> > Signed-off-by: Marcus Folkesson 
> > ---
> >
> >  drivers/mtd/nand/raw/atmel/nand-controller.c | 10 ++
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
> > b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > index ee4ec6da58..00d7e177b9 100644
> > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > @@ -568,12 +568,9 @@ static void atmel_nfc_copy_to_sram(struct nand_chip 
> > *chip, const u8 *buf,
> >   struct mtd_info *mtd = nand_to_mtd(chip);
> >   struct atmel_nand *nand = to_atmel_nand(chip);
> >   struct atmel_hsmc_nand_controller *nc;
> > - int ret = -EIO;
> >
> >   nc = to_hsmc_nand_controller(nand->controller);
> > -
> > - if (ret)
> > - memcpy_toio(nc->sram.virt, buf, mtd->writesize);
> > + memcpy_toio(nc->sram.virt, buf, mtd->writesize);
> >
> >   if (oob_required)
> >   memcpy_toio(nc->sram.virt + mtd->writesize, chip->oob_poi,
> > @@ -586,12 +583,9 @@ static void atmel_nfc_copy_from_sram(struct nand_chip 
> > *chip, u8 *buf,
> >   struct mtd_info *mtd = nand_to_mtd(chip);
> >   struct atmel_nand *nand = to_atmel_nand(chip);
> >   struct atmel_hsmc_nand_controller *nc;
> > - int ret = -EIO;
> >
> >   nc = to_hsmc_nand_controller(nand->controller);
> > -
> > - if (ret)
> > - memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
> > + memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
> >
> >   if (oob_required)
> >   memcpy_fromio(chip->oob_poi, nc->sram.virt + mtd->writesize,
> > --
> > 2.45.1
> >



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

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

Re: [PATCH v8 03/23] net: wget: allow EFI boot

[Jerome Forissier]

On 8/9/24 12:53, Ilias Apalodimas wrote:
> On Wed, 7 Aug 2024 at 20:12, Jerome Forissier
>  wrote:
>>
>> wget followed by bootefi currently fails as follows:
>>
>>  U-Boot> wget 20 192.168.0.30:helloworld.efi
>>  Waiting for Ethernet connection... done.
>>  HTTP/1.0 200 OK
>>  Packets received 13, Transfer Successful
>>  Bytes transferred = 12720 (31b0 hex)
>>  U-Boot> bootefi 20
>>  No UEFI binary known at 20
>>  U-Boot>
>>
>> Fix the problem by adding the missing efi_set_bootdev() call.
>>
>> Signed-off-by: Jerome Forissier 
>> ---
>>  net/wget.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/net/wget.c b/net/wget.c
>> index 0e4dc5159d0..cf7681a4e79 100644
>> --- a/net/wget.c
>> +++ b/net/wget.c
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -429,6 +430,9 @@ static void wget_handler(uchar *pkt, u16 dport,
>> case WGET_TRANSFERRED:
>> printf("Packets received %d, Transfer Successful\n", 
>> packets);
>> net_set_state(wget_loop_state);
>> +   efi_set_bootdev("Net", "", image_url,
>> +   map_sysmem(image_load_addr, 0),
>> +   net_boot_file_size);
> 
> Don't you need an unmap_sysmem() once this completes?

I wondered the same thing but where should the unmap call happen?
This pattern exists in boot/bootmeth_efi.c, cmd/load.c, fs/fs.c and net/tftp.c.
In this series I have blindly copied it into net/wget.c and net/lwip/wget.c and
net/lwip/tftp.c as well. It seems it does somthing in the sandbox only so do we
really care?

Thanks,
-- 
Jerome

> 
> Thanks
> /Ilias
>> break;
>> }
>>  }
>> --
>> 2.40.1
>>

Re: [PATCH v2] remoteproc: uclass: Modify uc_pdata->name to use combination of device name and device's parent name

[Roger Quadros]

On 07/08/2024 12:08, MD Danish Anwar wrote:
> uc_pdata->name is populated from device tree property "remoteproc-name".
> For those devcices that don't set "remoteproc-name", uc_pdata->name
> falls back to dev->name.
> 
> If two devices have same name, this will result into uc_pdata->name not
> being unique and rproc_init() will fail.
> 
> Fix this by using combination of dev->name and dev->parent->name instead
> of using just the dev->name to populate uc_pdata->name.
> 
> Signed-off-by: MD Danish Anwar 

Reviewed-by: Roger Quadros 

[PATCH] mtd: nand: raw: atmel: remove unnecessary return value

[Marcus Folkesson]

The condition 'ret' is always true as it is never set to other than
-EIO.

Remove 'ret' and the condition for copy.

Signed-off-by: Marcus Folkesson 
---

 drivers/mtd/nand/raw/atmel/nand-controller.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
b/drivers/mtd/nand/raw/atmel/nand-controller.c
index ee4ec6da58..00d7e177b9 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -568,12 +568,9 @@ static void atmel_nfc_copy_to_sram(struct nand_chip *chip, 
const u8 *buf,
struct mtd_info *mtd = nand_to_mtd(chip);
struct atmel_nand *nand = to_atmel_nand(chip);
struct atmel_hsmc_nand_controller *nc;
-   int ret = -EIO;
 
nc = to_hsmc_nand_controller(nand->controller);
-
-   if (ret)
-   memcpy_toio(nc->sram.virt, buf, mtd->writesize);
+   memcpy_toio(nc->sram.virt, buf, mtd->writesize);
 
if (oob_required)
memcpy_toio(nc->sram.virt + mtd->writesize, chip->oob_poi,
@@ -586,12 +583,9 @@ static void atmel_nfc_copy_from_sram(struct nand_chip 
*chip, u8 *buf,
struct mtd_info *mtd = nand_to_mtd(chip);
struct atmel_nand *nand = to_atmel_nand(chip);
struct atmel_hsmc_nand_controller *nc;
-   int ret = -EIO;
 
nc = to_hsmc_nand_controller(nand->controller);
-
-   if (ret)
-   memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
+   memcpy_fromio(buf, nc->sram.virt, mtd->writesize);
 
if (oob_required)
memcpy_fromio(chip->oob_poi, nc->sram.virt + mtd->writesize,
-- 
2.45.1

Re: [PATCH v2] remoteproc: uclass: Modify uc_pdata->name to use combination of device name and device's parent name

[Andrew Davis]

On 8/7/24 4:08 AM, MD Danish Anwar wrote:

uc_pdata->name is populated from device tree property "remoteproc-name".
For those devcices that don't set "remoteproc-name", uc_pdata->name
falls back to dev->name.

If two devices have same name, this will result into uc_pdata->name not
being unique and rproc_init() will fail.

Fix this by using combination of dev->name and dev->parent->name instead
of using just the dev->name to populate uc_pdata->name.

Signed-off-by: MD Danish Anwar 
---


Reviewed-by: Andrew Davis 


Cc: Andrew Davis 

Failure Example:
In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have
dev->name as "pru@34000" although their parent name is different.

pru0_0 has dev->name as "pru@34000" and parent name as "icssg@3000"
pru1_0 has dev->name as "pru@34000" and parent name as "icssg@3008"

rproc_init() fails for pru1_0 as the the uc_pdata->name becomes same as the 
pru0_0.
More details on this issue can be found here [3]. It was suggested to use a
different combination if `dev->name` is not unique by Andrew Davis 
 [4]

Failure Logs:
rproc_pre_probe: 'pru@34000': using fdt
rproc_pre_probe: 'pru@34000': using fdt
rproc_pre_probe: pru@34000 duplicate name 'pru@34000'
_rproc_probe_dev: pru@34000: Failed to initialize - -22
rproc_boot: rproc_init() failed: -22

To fix it, this commit uses combination of dev and dev's parent name.

After this commit,
pru0_0 uc->pdata->name = "pru@34000-icssg@3000"
pru1_0 uc->pdata->name = "pru@34000-icssg@3008"

Both the names are unique, thus rproc_init() succeeds.

Changes since v1:
*) Instead of hardcoding rproc_name_size to 256, changed it to be equal to
strlen(dev->name) + strlen(dev->parent->name) + 2 as suggested by
Roger Quadros 
  *) Added check for malloc failure as suggested by Roger Quadros 


[v1] https://lore.kernel.org/all/20240719085908.3564171-1-danishan...@ti.com/
[1] 
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1276
[2] 
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1417
[3] https://lore.kernel.org/all/5cda289f-1d14-41f6-84e3-ff1d1034b...@ti.com/
[4] https://lore.kernel.org/all/e48f5818-182c-47ab-b384-379659830...@ti.com/

  drivers/remoteproc/rproc-uclass.c | 16 +---
  1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/rproc-uclass.c 
b/drivers/remoteproc/rproc-uclass.c
index e64354dd52..3233ff8041 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -158,9 +158,19 @@ static int rproc_pre_probe(struct udevice *dev)
uc_pdata->driver_plat_data = pdata->driver_plat_data;
}
  
-	/* Else try using device Name */

-   if (!uc_pdata->name)
-   uc_pdata->name = dev->name;
+   /* Else try using a combination of device Name and devices's parent's 
name */
+   if (!uc_pdata->name) {
+   /* 2 in the rproc_name_size indicates 1 for null and one for 
'-' */
+   int rproc_name_size = strlen(dev->name) + 
strlen(dev->parent->name) + 2;
+   char *buf;
+
+   buf = malloc(rproc_name_size);
+   if (!buf)
+   return -ENOMEM;
+
+   snprintf(buf, rproc_name_size, "%s-%s", dev->name, 
dev->parent->name);
+   uc_pdata->name = buf;
+   }
if (!uc_pdata->name) {
debug("Unnamed device!");
return -EINVAL;

base-commit: 6f4c31c2b658358628b5b0fa801f55c7477c7585

Re: [PATCH v8 00/23] Introduce the lwIP network stack

[Jerome Forissier]

On 8/8/24 19:24, Tom Rini wrote:
> On Thu, Aug 08, 2024 at 06:41:02PM +0200, Jerome Forissier wrote:
>>
>>
>> On 8/7/24 22:44, Tom Rini wrote:
>>> On Wed, Aug 07, 2024 at 07:11:44PM +0200, Jerome Forissier wrote:
>>>
 This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
 library for the network stack" [1]. The goal is to introduce the lwIP 
 TCP/IP
 stack [2] [3] as an alternative to the current implementation in net/,
 selectable with Kconfig, and ultimately keep only lwIP if possible. Some
 reasons for doing so are:
 - Make the support of HTTPS in the wget command easier. Javier T. and
 Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do
 so. With that it becomes possible to fetch and launch a distro installer
 such as Debian etc. using a secure, authenticated connection directly
 from the U-Boot shell. Several use cases:
   * Authentication: prevent MITM attack (third party replacing the
 binary with a different one)
   * Confidentiality: prevent third parties from grabbing a copy of the
 image as it is being downloaded
   * Allow connection to servers that do not support plain HTTP anymore
 (this is becoming more and more common on the Internet these days)
 - Possibly benefit from additional features implemented in lwIP
 - Less code to maintain in U-Boot

 Prior to applying this series, the lwIP stack needs to be added as a
 Git subtree with the following command:

  $  git subtree add --squash --prefix lib/lwip/lwip 
 https://git.savannah.gnu.org/git/lwip.git STABLE-2_2_0_RELEASE
>>>
>>> For v9, I think it would be good to do a CI run with NET_LWIP default
>>> and seeing what fails from that too. There's a few problems still
>>> leading to a lot of failures, in that case. Thanks.
>>
>> I pushed my branch to GitHub [1] and there's a failure in the
>> tools_only_macOS job [2]. Any idea what is going on? I tried twice and
>> it failed twice :-/
>> Om my Linux machine, "make tools-only_config tools-only" works
>> fine.
>>
>> [1] https://github.com/u-boot/u-boot/pull/635
>> [2] 
>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results
> 
> Alright so from [2] going to the job and then downloading the raw log (it's
> huge, firefox gets mad for me), scrolling down until it's not the git clone we
> see:
> 2024-08-08T14:36:30.0865130Z   HOSTCC  scripts/basic/fixdep
> 2024-08-08T14:36:30.8641660Z   HOSTCC  scripts/kconfig/conf.o
> 2024-08-08T14:36:30.9645180Z   LEX scripts/kconfig/zconf.lex.c
> 2024-08-08T14:36:31.0545650Z   YACCscripts/kconfig/zconf.tab.c
> 2024-08-08T14:36:33.2374910Z   HOSTCC  scripts/kconfig/zconf.tab.o
> 2024-08-08T14:36:34.9997050Z   HOSTLD  scripts/kconfig/conf
> 2024-08-08T14:36:36.5552790Z generated_defconfig:7:warning: unexpected data:  
> # CONFIG_SANDBOX_
> SDL is not set
> 2024-08-08T14:36:36.5666380Z generated_defconfig:12:warning: unexpected data: 
>  # CONFIG_BOOTSTD
> _FULL is not set
> 2024-08-08T14:36:36.5724560Z generated_defconfig:13:warning: unexpected data: 
>  # CONFIG_BOOTMET
> H_CROS is not set
> 2024-08-08T14:36:36.5742720Z generated_defconfig:14:warning: unexpected data: 
>  # CONFIG_BOOTMET
> H_VBE is not set
> 2024-08-08T14:36:36.5752700Z generated_defconfig:17:warning: unexpected data: 
>  # CONFIG_CMD_BOO
> TD is not set
> 2024-08-08T14:36:36.5772400Z generated_defconfig:18:warning: unexpected data: 
>  # CONFIG_CMD_BOO
> TM is not set
> 2024-08-08T14:36:36.5788060Z generated_defconfig:19:warning: unexpected data: 
>  # CONFIG_CMD_BOO
> TI is not set
> 2024-08-08T14:36:36.5792360Z generated_defconfig:20:warning: unexpected data: 
>  # CONFIG_CMD_ELF
>  is not set
> 2024-08-08T14:36:36.5828400Z generated_defconfig:21:warning: unexpected data: 
>  # CONFIG_CMD_EXTENSION is not set
> 2024-08-08T14:36:36.5840470Z generated_defconfig:22:warning: unexpected data: 
>  # CONFIG_CMD_DAT
> E is not set
> 2024-08-08T14:36:36.5938540Z generated_defconfig:26:warning: unexpected data: 
>  # CONFIG_ACPIGEN
>  is not set
> 2024-08-08T14:36:36.5974000Z generated_defconfig:35:warning: unexpected data: 
>  # CONFIG_VIRTIO_MMIO is not set
> 2024-08-08T14:36:36.5985430Z generated_defconfig:36:warning: unexpected data: 
>  # CONFIG_VIRTIO_PCI is not set
> 2024-08-08T14:36:36.6045140Z generated_defconfig:37:warning: unexpected data: 
>  # CONFIG_VIRTIO_SANDBOX is not set
> 2024-08-08T14:36:36.6053060Z generated_defconfig:38:warning: unexpected data: 
>  # CONFIG_GENERATE_ACPI_TABLE is not set
> 2024-08-08T14:36:36.6068760Z generated_defconfig:39:warning: unexpected data: 
>  # CONFIG_EFI_LOADER is not set
> 2024-08-08T14:36:36.6088140Z #
> 2024-08-08T14:36:36.6121560Z # configuration written to .config
> 2024-08-08T14:36:36.6130190Z #
> 2024-08-08T14:36:42.5830900Z scripts/kconfig/conf  --syncconfig Kconfig
> 2024-08-08T14:36:43.9105630Z .config:284:warning: symbol value '' invalid for 
> AVB_BUF_ADDR
> 2024-08-08T14

Re: pinctrl warning on sandbox

[Sean Anderson]

Hi Simon,

On 8/7/24 19:17, Simon Glass wrote:

Hi Sean,

I was looking at [1] and bisected the message to this commit:

7f0f1806e3a (refs/bisect/bad) test: pinmux: Add test for pin muxing

I'm not quite sure what is going on, but could you please take a look?

Regards,
Simon

[1] https://source.denx.de/u-boot/u-boot/-/issues/2


That test run is pretty old. Does the error always occur during EFI tests?
You said in IRC it occurs on current master; can you send a link?

--Sean

Please pull v2 u-boot-i2c

[Heiko Schocher]

Hello Tom,

please pull from u-boot-i2c master, sorted out the DM_I2C patches from Anatolij,
to seperate pull request for next.

The following changes since commit eb8e25c000d185ece0136b13cca73084eb980253:

  Merge tag 'u-boot-nand-20240808' of https://source.denx.de/u-boot/custodians/u-boot-nand-flash 
(2024-08-08 16:15:06 -0600)


are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-i2c.git 
tags/i2cfixes-v2-for-v2024-10-rc3

for you to fetch changes up to ec07bcc8eafb8d201d15facc969fe96600660095:

  i2c: imx_lpi2c: Support read transfers longer than 256 bytes (2024-08-09 
14:46:49 +0200)


i2c updates for v2024.10-rc3 (second try)

- i2c: samsung: Support platforms other than EXYNOS4 and EXYNOS5
  from David

- imx_lpi2c: cleanups and support read transfers longer than 256 bytes
  from Fedor

- pca954x: Remove pointer to GD
  from Michal

- i2c: mux: Fix error path in i2c-arb-gpio
  from Michal


David Virag (2):
  i2c: samsung: Drop s3c24x0 specific code.
  i2c: samsung: Support platforms other than EXYNOS4 and EXYNOS5

Fedor Ross (3):
  i2c: imx_lpi2c: Fix a typo in bus_i2c_receive
  i2c: imx_lpi2c: Replace hard-coded bus speed value with bus->speed_hz
  i2c: imx_lpi2c: Support read transfers longer than 256 bytes

Michal Simek (2):
  i2c: pca954x: Remove pointer to GD
  i2c: mux: Fix error path in i2c-arb-gpio

 drivers/i2c/Kconfig|  2 +-
 drivers/i2c/exynos_hs_i2c.c| 25 +
 drivers/i2c/imx_lpi2c.c| 87 
---

 drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 11 ---
 drivers/i2c/muxes/pca954x.c|  3 ---
 drivers/i2c/s3c24x0_i2c.c  | 32 

 drivers/i2c/s3c24x0_i2c.h  |  2 ++
 7 files changed, 108 insertions(+), 54 deletions(-)


Azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=117&view=results

Thanks!

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

Please pull u-boot-i2c next

[Heiko Schocher]

Hello Tom,

please pull from u-boot-i2c next

The following changes since commit 2078abaf00b63fc4f70f8a599b61a476e22352f3:

  Merge patch series "alist: Implement a pointer list / array of structs" 
(2024-08-07 08:51:25 -0600)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-i2c.git 
tags/i2cupdates-for-v2024-10-next

for you to fetch changes up to b08ee931ba55cf6196faf7f9d0613e325971f31f:

  board: vining_2000: convert to DM_I2C (2024-08-09 06:27:27 +0200)


i2c updates for v2024.10 next

- DM_I2C conversion for some remaining boards
  from Anatolij


Anatolij Gustschin (10):
  board: shc: convert to DM_I2C
  board: chiliboard: convert to DM_I2C
  board: cm-t43: convert to DM_I2C
  board: igep003x: convert to DM_I2C
  board: sl50: convert to DM_I2C
  board: rut: convert to DM_I2C
  board: novena: convert to DM_I2C
  board: vf610twr: convert to DM_I2C
  board: cm_fx6: convert to DM_I2C
  board: vining_2000: convert to DM_I2C

 board/bosch/shc/board.c |  22 +++---
 board/compulab/cm_fx6/cm_fx6.c  |   3 ++-
 board/compulab/cm_t43/cm_t43.c  |   2 --
 board/compulab/common/Makefile  |   8 +++-
 board/compulab/common/eeprom.c  |  14 +-
 board/compulab/common/eeprom.h  |   2 +-
 board/kosagi/novena/novena.c|  10 +-
 board/kosagi/novena/video.c | 140 
+++-

 board/softing/vining_2000/vining_2000.c |  25 -
 configs/am335x_igep003x_defconfig   |   2 +-
 configs/am335x_shc_defconfig|   4 +++-
 configs/am335x_shc_ict_defconfig|   4 +++-
 configs/am335x_shc_netboot_defconfig|   4 +++-
 configs/am335x_shc_sdboot_defconfig |   4 +++-
 configs/am335x_sl50_defconfig   |   2 +-
 configs/chiliboard_defconfig|   2 +-
 configs/cm_fx6_defconfig|   2 +-
 configs/cm_t43_defconfig|   3 ++-
 configs/novena_defconfig|   2 +-
 configs/rut_defconfig   |   2 +-
 configs/vf610twr_defconfig  |   2 +-
 configs/vf610twr_nand_defconfig |   2 +-
 configs/vining_2000_defconfig   |   2 +-
 23 files changed, 129 insertions(+), 134 deletions(-)

Azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=118&view=results

Thanks!

bye,
Heiko

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

Re: pinctrl warning on sandbox

[Simon Glass]

Hi Sean,

On Fri, 9 Aug 2024 at 07:31, Sean Anderson  wrote:
>
> Hi Simon,
>
> On 8/7/24 19:17, Simon Glass wrote:
> > Hi Sean,
> >
> > I was looking at [1] and bisected the message to this commit:
> >
> > 7f0f1806e3a (refs/bisect/bad) test: pinmux: Add test for pin muxing
> >
> > I'm not quite sure what is going on, but could you please take a look?
> >
> > Regards,
> > Simon
> >
> > [1] https://source.denx.de/u-boot/u-boot/-/issues/2
>
> That test run is pretty old. Does the error always occur during EFI tests?
> You said in IRC it occurs on current master; can you send a link?

Yes, it happens whenever sandbox is run with the device tree. This is
sandbox build from -next:

$ /tmp/b/sandbox/u-boot -D
Bloblist at b000 not found (err=-2)
sandbox_serial serial: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19


U-Boot 2024.10-rc2-00021-gb63f30d4ae6a-dirty (Aug 08 2024 - 12:46:24 -0600)

Reset Status: COLD
Model: sandbox
DRAM:  256 MiB

Warning: host_lo MAC addresses don't match:
Address in ROM is b2:e9:3c:a1:b3:05
Address in environment is 02:00:11:22:33:44
sandbox_serial serial: pinctrl_select_state_full: pinctrl_config_one: err=-38
Core:  117 devices, 61 uclasses, devicetree: board
WDT:   Started alarm-wdt with servicing every 1000ms (5s timeout)
NAND:  0 MiB
MMC:
Loading Environment from nowhere... OK
Warning: device tree node '/config/environment' not found
In:serial,cros-ec-keyb,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Model: sandbox
Net:   eth0: host_lo, eth1: host_enp14s0, eth2: host_eth6, eth3:
host_wlp15s0, eth4: host_docker0
Error: eth@10002000 No valid MAC address found.


Hit any key to stop autoboot:  0
=>

Regards,
Simon

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

[Simon Glass]

Hi Michal,

On Thu, 8 Aug 2024 at 23:39, Michal Simek  wrote:
>
> Hi Simon,
>
> On 8/8/24 16:28, Simon Glass wrote:
> > Hi Michal,
> >
> > On Wed, 7 Aug 2024 at 23:31, Michal Simek  wrote:
> >>
> >>
> >>
> >> On 8/7/24 16:36, Simon Glass wrote:
> >>> Hi Prasad,
> >>>
> >>> On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad  
> >>> wrote:
> 
>  Hi Glass,
> 
> > -Original Message-
> > From: Simon Glass 
> > Sent: Wednesday, August 7, 2024 3:21 AM
> > To: Kummari, Prasad 
> > Cc: u-boot@lists.denx.de; git (AMD-Xilinx) ; Simek, Michal
> > ; Abbarapu, Venkatesh
> > ; g...@xilinx.com;
> > ja...@amarulasolutions.com; n-fran...@ti.com; d-g...@ti.com
> > Subject: Re: [PATCH] cmd: sf: prevent overwriting the reserved memory
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > Hi Prasad,
> >
> > On Tue, 6 Aug 2024 at 06:08, Prasad Kummari  
> > wrote:
> >>
> >> Added LMB API to prevent SF command from overwriting reserved memory
> >> areas. The current SPI code does not use LMB APIs for loading data
> >> into memory addresses. To resolve this, LMB APIs were added to check
> >> the load address of an SF command and ensure it does not overwrite
> >> reserved memory addresses. Similar checks are used in TFTP, serial
> >> load, and boot code to prevent overwriting reserved memory.
> >
> > The SPI flash may be used to load other things, not just an OS. What is 
> > your
> > use case or problem here?
> 
>  [Prasad]:  We have observed that SF command can overwrite the reserved 
>  area without throwing any errors or warnings.
> This issue was noticed when the TF-A area is reserved in the Device 
>  Tree at address 0xf00. The sf command is
> corrupting the reserved area,  and U-Boot relocation address too.
> 
>  EX: TF-A reserved at ddr address 0xf00
> 
>  Versal NET> sf read 0x0f00 0x0 0x100 > Overwriting 
>  reserved area.
>  device 0 offset 0x0, size 0x100
>  SF: 256 bytes @ 0x0 Read: OK
> 
> U-boot relocation address relocaddr   = 0x7fec2000
> 
>  Versal NET> sf write 0x77ec2000 0x0 0x100   --> 
>  Overwriting reserved area.
>  device 0 offset 0x0, size 0x100
>  SF: 256 bytes @ 0x0 Written: OK
> >>>
> >>> Yes. There are many things which can overwrite memory, e.g. the mw
> >>> command. It is a boot loader so this is normal.
> >>>
> >>> What image are you loading here?
> >>
> >> In spi boot it can be Kernel/rootfs but at the end of day it doesn't 
> >> really matter.
> >
> > OK, in that case yes it should use lmb. That was the question I was
> > trying to understand.
> >
> >>
> >> We have protection for srec, fs load, tftp and wget already.
> >>
> >> c6855195e4b4 ("loads: Block writes into LMB reserved areas of U-Boot")
> >> aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> >> a156c47e39ad ("tftp: prevent overwriting reserved memory")
> >> 04592adbdb99 ("net: wget: prevent overwriting reserved memory")
> >>
> >> And this is just +1 patch to protect sf command that it doesn't touch 
> >> reserved
> >> location.
> >> The same code should be used for other commands(nand, usb, etc) which 
> >> loading
> >> block of data to memory because all of them shouldn't rewrite reserved 
> >> memory.
> >>
> >> In connection to mw/mtest/etc command protection can be also done but not 
> >> sure
> >> if this is useful because you normally not using them for booting.
> >
> > Exactly.
> >
> > I am hoping that we can pull SPI flash into bootstd...has anyone
> > looked at that? Are you using scripts or is there a special bootmeth?
>
> We didn't find this issue in connection to boot. As I wrote in another reply 
> we
> found it via spi testcases where TF-A was placed lower in DDR and test 
> overwrite
> it without any other evidence. Part of the reason is that protection units are
> not enabled to protect secure FW.

Do you mean the sandbox test test/dm/sf.c ? Or something else? If the
former, then we could mark dm_test_spi_flash() with CONFIG_SANDBOX

Regards,
Simon

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

[Michal Simek]

On 8/9/24 16:44, Simon Glass wrote:

Hi Michal,

On Thu, 8 Aug 2024 at 23:39, Michal Simek  wrote:


Hi Simon,

On 8/8/24 16:28, Simon Glass wrote:

Hi Michal,

On Wed, 7 Aug 2024 at 23:31, Michal Simek  wrote:




On 8/7/24 16:36, Simon Glass wrote:

Hi Prasad,

On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad  wrote:


Hi Glass,


-Original Message-
From: Simon Glass 
Sent: Wednesday, August 7, 2024 3:21 AM
To: Kummari, Prasad 
Cc: u-boot@lists.denx.de; git (AMD-Xilinx) ; Simek, Michal
; Abbarapu, Venkatesh
; g...@xilinx.com;
ja...@amarulasolutions.com; n-fran...@ti.com; d-g...@ti.com
Subject: Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.


Hi Prasad,

On Tue, 6 Aug 2024 at 06:08, Prasad Kummari  wrote:


Added LMB API to prevent SF command from overwriting reserved memory
areas. The current SPI code does not use LMB APIs for loading data
into memory addresses. To resolve this, LMB APIs were added to check
the load address of an SF command and ensure it does not overwrite
reserved memory addresses. Similar checks are used in TFTP, serial
load, and boot code to prevent overwriting reserved memory.


The SPI flash may be used to load other things, not just an OS. What is your
use case or problem here?


[Prasad]:  We have observed that SF command can overwrite the reserved area 
without throwing any errors or warnings.
This issue was noticed when the TF-A area is reserved in the Device Tree at 
address 0xf00. The sf command is
corrupting the reserved area,  and U-Boot relocation address too.

EX: TF-A reserved at ddr address 0xf00

 Versal NET> sf read 0x0f00 0x0 0x100 > Overwriting 
reserved area.
 device 0 offset 0x0, size 0x100
 SF: 256 bytes @ 0x0 Read: OK

U-boot relocation address relocaddr   = 0x7fec2000

 Versal NET> sf write 0x77ec2000 0x0 0x100   --> Overwriting 
reserved area.
 device 0 offset 0x0, size 0x100
 SF: 256 bytes @ 0x0 Written: OK


Yes. There are many things which can overwrite memory, e.g. the mw
command. It is a boot loader so this is normal.

What image are you loading here?


In spi boot it can be Kernel/rootfs but at the end of day it doesn't really 
matter.


OK, in that case yes it should use lmb. That was the question I was
trying to understand.



We have protection for srec, fs load, tftp and wget already.

c6855195e4b4 ("loads: Block writes into LMB reserved areas of U-Boot")
aa3c609e2be5 ("fs: prevent overwriting reserved memory")
a156c47e39ad ("tftp: prevent overwriting reserved memory")
04592adbdb99 ("net: wget: prevent overwriting reserved memory")

And this is just +1 patch to protect sf command that it doesn't touch reserved
location.
The same code should be used for other commands(nand, usb, etc) which loading
block of data to memory because all of them shouldn't rewrite reserved memory.

In connection to mw/mtest/etc command protection can be also done but not sure
if this is useful because you normally not using them for booting.


Exactly.

I am hoping that we can pull SPI flash into bootstd...has anyone
looked at that? Are you using scripts or is there a special bootmeth?


We didn't find this issue in connection to boot. As I wrote in another reply we
found it via spi testcases where TF-A was placed lower in DDR and test overwrite
it without any other evidence. Part of the reason is that protection units are
not enabled to protect secure FW.


Do you mean the sandbox test test/dm/sf.c ? Or something else? If the
former, then we could mark dm_test_spi_flash() with CONFIG_SANDBOX


pytest one and I think it was this one.
https://github.com/Xilinx/u-boot-xlnx/blob/master/test/py/tests/test_spi.py

Love is working on sending this test upstream as he did with others.

Thanks,
Michal

[PATCH] tqma6q_mba6: Convert to watchdog driver model

[Fabio Estevam]

From: Fabio Estevam 

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

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

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/imx6dl-mba6b-u-boot.dtsi |  3 +++
 arch/arm/dts/imx6q-mba6b-u-boot.dtsi  |  3 +++
 arch/arm/dts/imx6qdl-mba6-u-boot.dtsi | 15 +++
 configs/tqma6dl_mba6_mmc_defconfig|  3 +++
 configs/tqma6dl_mba6_spi_defconfig|  3 +++
 configs/tqma6q_mba6_mmc_defconfig |  3 +++
 configs/tqma6q_mba6_spi_defconfig |  3 +++
 configs/tqma6s_mba6_mmc_defconfig |  3 +++
 configs/tqma6s_mba6_spi_defconfig |  3 +++
 9 files changed, 39 insertions(+)
 create mode 100644 arch/arm/dts/imx6dl-mba6b-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6q-mba6b-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-mba6-u-boot.dtsi

diff --git a/arch/arm/dts/imx6dl-mba6b-u-boot.dtsi 
b/arch/arm/dts/imx6dl-mba6b-u-boot.dtsi
new file mode 100644
index ..bb17ba9b4249
--- /dev/null
+++ b/arch/arm/dts/imx6dl-mba6b-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "imx6qdl-mba6-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6q-mba6b-u-boot.dtsi 
b/arch/arm/dts/imx6q-mba6b-u-boot.dtsi
new file mode 100644
index ..bb17ba9b4249
--- /dev/null
+++ b/arch/arm/dts/imx6q-mba6b-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "imx6qdl-mba6-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6qdl-mba6-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-mba6-u-boot.dtsi
new file mode 100644
index ..78457ef68f4f
--- /dev/null
+++ b/arch/arm/dts/imx6qdl-mba6-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <&wdog1>;
+   bootph-pre-ram;
+   };
+};
+
+&wdog1 {
+   bootph-pre-ram;
+};
diff --git a/configs/tqma6dl_mba6_mmc_defconfig 
b/configs/tqma6dl_mba6_mmc_defconfig
index 1a1d253c50ee..1534a2e9262a 100644
--- a/configs/tqma6dl_mba6_mmc_defconfig
+++ b/configs/tqma6dl_mba6_mmc_defconfig
@@ -65,5 +65,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/tqma6dl_mba6_spi_defconfig 
b/configs/tqma6dl_mba6_spi_defconfig
index c6a1c7cf3d7d..5eaa9eb270ce 100644
--- a/configs/tqma6dl_mba6_spi_defconfig
+++ b/configs/tqma6dl_mba6_spi_defconfig
@@ -69,5 +69,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/tqma6q_mba6_mmc_defconfig 
b/configs/tqma6q_mba6_mmc_defconfig
index 27f949c6ef68..3fcc1f8d54e1 100644
--- a/configs/tqma6q_mba6_mmc_defconfig
+++ b/configs/tqma6q_mba6_mmc_defconfig
@@ -65,5 +65,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/tqma6q_mba6_spi_defconfig 
b/configs/tqma6q_mba6_spi_defconfig
index 5d3ce79c35d9..a7ffc9edb5b4 100644
--- a/configs/tqma6q_mba6_spi_defconfig
+++ b/configs/tqma6q_mba6_spi_defconfig
@@ -69,5 +69,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/tqma6s_mba6_mmc_defconfig 
b/configs/tqma6s_mba6_mmc_defconfig
index a9ed0d3fc2c6..7839c4858478 100644
--- a/configs/tqma6s_mba6_mmc_defconfig
+++ b/configs/tqma6s_mba6_mmc_defconfig
@@ -65,5 +65,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/tqma6s_mba6_spi_defconfig 
b/configs/tqma6s_mba6_spi_defconfig
index 9cd8c3dd20f4..c3bb44025b34 100644
--- a/configs/tqma6s_mba6_spi_defconfig
+++ b/configs/tqma6s_mba6_spi_defconfig
@@ -69,5 +69,8 @@ CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_THERMAL=y
+CONFIG_IMX_WATCHDOG=y
-- 
2.34.1

Re: [PATCH] usb: dwc3-generic: fix CONFIG_DM_REGULATOR-off case

[Caleb Connolly]

On 09/08/2024 07:19, Jan Kiszka wrote:

On 08.08.24 16:27, Caleb Connolly wrote:

Hi Jan,

On 08/08/2024 10:51, Jan Kiszka wrote:

From: Jan Kiszka 

When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account
for that so that targets like the IOT2050 will work again.

Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus
regulator")
Signed-off-by: Jan Kiszka 
---
   drivers/usb/dwc3/dwc3-generic.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c
b/drivers/usb/dwc3/dwc3-generic.c
index a9ba315463c..2ab41cbae45 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -246,12 +246,12 @@ static int dwc3_generic_host_probe(struct
udevice *dev)
   return rc;
     rc = device_get_supply_regulator(dev, "vbus-supply",
&priv->vbus_supply);
-    if (rc)
+    if (rc && rc != -ENOSYS)
   debug("%s: No vbus regulator found: %d\n", dev->name, rc);
   -    /* Only returns an error if regulator is valid and failed to
enable due to a driver issue */
+    /* Does not return an error if regulator is invalid - but does so
when DM_REGULATOR is disabled */
   rc = regulator_set_enable_if_allowed(priv->vbus_supply, true);
-    if (rc)
+    if (rc && rc != -ENOSYS)


regulator_set_enable_if_allowed() will return 0 if the call to
regulator_set_enable() returns -ENOSYS

Maybe it would make sense to have the stub implementation of
regulator_set_enable_if_allowed() return 0?



Possible. Would that be the only case where a stub should not return
ENOSYS? All do so far.


Somewhat confusing to check for -ENOSYS here imo, since it isn't really
obvious when that would be the case.


But that would still leave is a with a misleading message, even if it is
just a debug output. The absence of a regulator is not per se a bug to
my understanding.


Ah good point.

Alternatively, maybe it would be easier to gate this code block with if 
(CONFIG_IS_ENABLED(DM_REGULATOR)?


But yeah maybe fine as is.

Reviewed-by: Caleb Connolly 


Jan


   return rc;
     hccr = (struct xhci_hccr *)priv->gen_priv.base;






--
// Caleb (they/them)

[PATCH] imx6-tqma6: Convert to OF_UPSTREAM

[Fabio Estevam]

From: Fabio Estevam 

Instead of using the local imx6-tqma6 devicetree copies from U-Boot,
convert the imx6-tqma6 target to OF_UPSTREAM so that the upstream
kernel devicetrees can be used instead.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/Makefile  |   4 -
 arch/arm/dts/imx6dl-mba6b.dts  |  21 ---
 arch/arm/dts/imx6dl-tqma6a.dtsi|  16 ---
 arch/arm/dts/imx6dl-tqma6b.dtsi|  16 ---
 arch/arm/dts/imx6q-mba6b.dts   |  20 ---
 arch/arm/dts/imx6q-tqma6a.dtsi |  16 ---
 arch/arm/dts/imx6q-tqma6b.dtsi |  15 --
 arch/arm/dts/imx6qdl-tqma6.dtsi| 215 -
 arch/arm/dts/imx6qdl-tqma6a.dtsi   |  53 ---
 arch/arm/dts/imx6qdl-tqma6b.dtsi   |  33 -
 board/tq/tqma6/Kconfig |   1 +
 configs/tqma6dl_mba6_mmc_defconfig |   2 +-
 configs/tqma6dl_mba6_spi_defconfig |   2 +-
 configs/tqma6q_mba6_mmc_defconfig  |   2 +-
 configs/tqma6q_mba6_spi_defconfig  |   4 +-
 configs/tqma6s_mba6_mmc_defconfig  |   2 +-
 configs/tqma6s_mba6_spi_defconfig  |   2 +-
 17 files changed, 8 insertions(+), 416 deletions(-)
 delete mode 100644 arch/arm/dts/imx6dl-mba6b.dts
 delete mode 100644 arch/arm/dts/imx6dl-tqma6a.dtsi
 delete mode 100644 arch/arm/dts/imx6dl-tqma6b.dtsi
 delete mode 100644 arch/arm/dts/imx6q-mba6b.dts
 delete mode 100644 arch/arm/dts/imx6q-tqma6a.dtsi
 delete mode 100644 arch/arm/dts/imx6q-tqma6b.dtsi
 delete mode 100644 arch/arm/dts/imx6qdl-tqma6.dtsi
 delete mode 100644 arch/arm/dts/imx6qdl-tqma6a.dtsi
 delete mode 100644 arch/arm/dts/imx6qdl-tqma6b.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 871cfbbebabd..2d931c23fc83 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -764,8 +764,6 @@ dtb-y += \
imx6dl-icore.dtb \
imx6dl-icore-mipi.dtb \
imx6dl-icore-rqs.dtb \
-   imx6dl-mba6a.dtb \
-   imx6dl-mba6b.dtb \
imx6dl-mamoj.dtb \
imx6dl-nitrogen6x.dtb \
imx6dl-pico.dtb \
@@ -815,8 +813,6 @@ dtb-y += \
imx6q-kp.dtb \
imx6q-logicpd.dtb \
imx6q-marsboard.dtb \
-   imx6q-mba6a.dtb \
-   imx6q-mba6b.dtb \
imx6q-mccmon6.dtb\
imx6q-nitrogen6x.dtb \
imx6q-novena.dtb \
diff --git a/arch/arm/dts/imx6dl-mba6b.dts b/arch/arm/dts/imx6dl-mba6b.dts
deleted file mode 100644
index 610b19d2db0f..
--- a/arch/arm/dts/imx6dl-mba6b.dts
+++ /dev/null
@@ -1,21 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright 2013 Sascha Hauer, Pengutronix
- *
- * Copyright 2013-2021 TQ-Systems GmbH
- * Author: Markus Niebel 
- */
-
-/dts-v1/;
-
-#include 
-#include "imx6dl-tqma6b.dtsi"
-#include "imx6qdl-mba6.dtsi"
-#include "imx6qdl-mba6b.dtsi"
-#include "imx6dl-mba6.dtsi"
-
-/ {
-   model = "TQ TQMa6S/DL on MBa6x";
-   compatible = "tq,imx6dl-mba6x-b", "tq,mba6b",
-"tq,imx6dl-tqma6dl-b", "fsl,imx6dl";
-};
diff --git a/arch/arm/dts/imx6dl-tqma6a.dtsi b/arch/arm/dts/imx6dl-tqma6a.dtsi
deleted file mode 100644
index e891ef9b0091..
--- a/arch/arm/dts/imx6dl-tqma6a.dtsi
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright 2013 Sascha Hauer, Pengutronix
- * Copyright 2013-2017 Markus Niebel 
- */
-
-#include "imx6dl.dtsi"
-#include "imx6qdl-tqma6a.dtsi"
-#include "imx6qdl-tqma6.dtsi"
-
-/ {
-   memory@1000 {
-   device_type = "memory";
-   reg = <0x1000 0x2000>;
-   };
-};
diff --git a/arch/arm/dts/imx6dl-tqma6b.dtsi b/arch/arm/dts/imx6dl-tqma6b.dtsi
deleted file mode 100644
index 38cd8501a886..
--- a/arch/arm/dts/imx6dl-tqma6b.dtsi
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright 2013 Sascha Hauer, Pengutronix
- * Copyright 2013-2017 Markus Niebel 
- */
-
-#include "imx6dl.dtsi"
-#include "imx6qdl-tqma6b.dtsi"
-#include "imx6qdl-tqma6.dtsi"
-
-/ {
-   memory@1000 {
-   device_type = "memory";
-   reg = <0x1000 0x2000>;
-   };
-};
diff --git a/arch/arm/dts/imx6q-mba6b.dts b/arch/arm/dts/imx6q-mba6b.dts
deleted file mode 100644
index 02c9f3e91b8f..
--- a/arch/arm/dts/imx6q-mba6b.dts
+++ /dev/null
@@ -1,20 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright 2013 Sascha Hauer, Pengutronix
- *
- * Copyright 2013-2021 TQ-Systems GmbH
- * Author: Markus Niebel 
- */
-
-/dts-v1/;
-
-#include "imx6q-tqma6b.dtsi"
-#include "imx6qdl-mba6.dtsi"
-#include "imx6qdl-mba6b.dtsi"
-#include "imx6q-mba6.dtsi"
-
-/ {
-   model = "TQ TQMa6Q on MBa6x";
-   compatible = "tq,imx6q-mba6x-b", "tq,mba6b",
-"tq,imx6q-tqma6q-b", "fsl,imx6q";
-};
diff --git a/arch/arm/dts/imx6q-tqma6a.dtsi b/arch/arm/dts/imx6q-tqma6a.dtsi
deleted file mode 100644
index ab4c07c13a13..
--- a/arch/arm/dts/imx6q-tqma6a.dtsi
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright 2013 Sascha Hauer, Pengutronix
- * Copyright 

[PATCH] env: remove vars that are not in default env

[Ravi Minnikanti]

current env_set_default_vars() doesn't delete
var that are not in the imported env. hashtable
removes vars that are not in the imported
env but present in the current env only if H_NOCLEAR
flag is not set.

This change is to avoid passing H_NOCLEAR flag if
specific vars are passed to env_set_default_vars()

Test:

Without this change:
Marvell>> env default boot_mode
Marvell>>

With the change:
Marvell>> env default boot_mode
WARNING: 'boot_mode' not in imported env, deleting it!

Signed-off-by: rminnikanti 
---
 env/common.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/env/common.c b/env/common.c
index 8d47d72605..2f783e3a69 100644
--- a/env/common.c
+++ b/env/common.c
@@ -401,7 +401,15 @@ int env_set_default_vars(int nvars, char * const vars[], 
int flags)
 * Special use-case: import from default environment
 * (and use \0 as a separator)
 */
-   flags |= H_NOCLEAR | H_DEFAULT;
+
+   /* 
+* When vars are passed remove variables that are not in
+* the default environment.
+*/
+   if (!nvars)
+   flags |= H_NOCLEAR;
+
+   flags |= H_DEFAULT;
return himport_r(&env_htab, default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
-- 
2.25.1

Thanks,
Ravi

Re: [PATCH] sf: Add lock info option to sf command list

[Simon Glass]

Hi Venkatesh,

On Fri, 9 Aug 2024 at 03:39, Venkatesh Yadav Abbarapu
 wrote:
>
> Many SPI flashes have status/OTP bit for TOP or BOTTOM selection
> in the status register that can protect selected regions of
> the SPI NOR.
>
> Take this bit into consideration while locking the region.
> The command "sf lockinfo" shows whether the flash is TOP or
> BOTTOM protected, based on this info the "offset" is provided to
> the "sf protect lock" command.
>
> Versal> sf erase 0 10
> SF: 1048576 bytes @ 0x0 Erased: OK
> Versal>sf lockinfo
> Flash is BOTTOM protected
> Versal> sf protect lock 0 2
> Versal> sf erase 0 2
> ERROR: flash area is locked
> Versal> sf protect unlock 0 2
> Versal> sf erase 0 2
> SF: 131072 bytes @ 0x0 Erased: OK
>
> Signed-off-by: Venkatesh Yadav Abbarapu 
> ---
>  cmd/sf.c   | 30 +-
>  drivers/mtd/spi/spi-nor-core.c | 16 
>  include/linux/mtd/spi-nor.h|  1 +
>  include/spi.h  |  3 +++
>  include/spi_flash.h|  8 
>  5 files changed, 57 insertions(+), 1 deletion(-)

Please can you add to doc/usage/cmd/sf.c and extend the test in
test/dm/sf.c ? Let me know if you need help with the test.

>
> diff --git a/cmd/sf.c b/cmd/sf.c
> index f43a2e08b3..62afa91057 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -413,6 +413,30 @@ static int do_spi_protect(int argc, char *const argv[])
> return ret == 0 ? 0 : 1;
>  }
>
> +static int do_spi_lock_info(int argc, char *const argv[])
> +{
> +   int ret;
> +
> +   if (argc != 1)
> +   return CMD_RET_USAGE;

Shouldn't be needed, see below.

> +
> +   ret = spi_flash_lock_info(flash);
> +   if (ret < 0) {
> +   printf("Flash info is not set\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   if (ret == BOTTOM_PROTECT) {
> +   printf("Flash is BOTTOM protected\n");
> +   return CMD_RET_SUCCESS;
> +   } else if (ret == TOP_PROTECT) {
> +   printf("Flash is TOP protected\n");
> +   return CMD_RET_SUCCESS;

return 0 is better than CMD_RET_SUCCESS, to avoid confusion that
success might be anything other than 0.

> +   }
> +
> +   return CMD_RET_FAILURE;
> +}
> +
>  enum {
> STAGE_ERASE,
> STAGE_CHECK,
> @@ -607,6 +631,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> ret = do_spi_flash_erase(argc, argv);
> else if (IS_ENABLED(CONFIG_SPI_FLASH_LOCK) && strcmp(cmd, "protect") 
> == 0)
> ret = do_spi_protect(argc, argv);
> +   else if (IS_ENABLED(CONFIG_SPI_FLASH_LOCK) && strcmp(cmd, "lockinfo") 
> == 0)
> +   ret = do_spi_lock_info(argc, argv);

Eek this is a mess. Before adding your feature, please create a patch
to refactor this code to use U_BOOT_CMD_WITH_SUBCMDS() like other
commands with subcommands.

> else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test"))
> ret = do_spi_flash_test(argc, argv);
> else
> @@ -632,7 +658,9 @@ U_BOOT_LONGHELP(sf,
> " or to start of mtd 
> `partition'\n"
>  #ifdef CONFIG_SPI_FLASH_LOCK
> "sf protect lock/unlock sector len  - protect/unprotect 'len' 
> bytes starting\n"
> -   " at address 'sector'"
> +   " at address 'sector'\n"
> +   "sf lockinfo- shows whether the flash 
> locking is top or bottom\n"
> +   " protected\n"
>  #endif
>  #ifdef CONFIG_CMD_SF_TEST
> "\nsf test offset len   - run a very basic destructive test"
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index aea611fef5..2114be1e61 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -1410,6 +1410,21 @@ static int stm_is_unlocked(struct spi_nor *nor, loff_t 
> ofs, uint64_t len)
>
> return stm_is_unlocked_sr(nor, ofs, len, status);
>  }
> +
> +static bool stm_lock_info(struct spi_nor *nor)
> +{
> +   int status;
> +
> +   status = read_sr(nor);
> +   if (status < 0)
> +   return status;
> +
> +   if (status & SR_TB)
> +   return BOTTOM_PROTECT;
> +
> +   return TOP_PROTECT;
> +}
> +
>  #endif /* CONFIG_SPI_FLASH_STMICRO */
>  #endif
>
> @@ -4145,6 +4160,7 @@ int spi_nor_scan(struct spi_nor *nor)
> nor->flash_lock = stm_lock;
> nor->flash_unlock = stm_unlock;
> nor->flash_is_unlocked = stm_is_unlocked;
> +   nor->flash_lock_info = stm_lock_info;
> }
>  #endif
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index d1dbf3eadb..48d39a7052 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -580,6 +580,7 @@ stru

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

[Simon Glass]

Hi Michal,

On Fri, 9 Aug 2024 at 08:47, Michal Simek  wrote:
>
>
>
> On 8/9/24 16:44, Simon Glass wrote:
> > Hi Michal,
> >
> > On Thu, 8 Aug 2024 at 23:39, Michal Simek  wrote:
> >>
> >> Hi Simon,
> >>
> >> On 8/8/24 16:28, Simon Glass wrote:
> >>> Hi Michal,
> >>>
> >>> On Wed, 7 Aug 2024 at 23:31, Michal Simek  wrote:
> 
> 
> 
>  On 8/7/24 16:36, Simon Glass wrote:
> > Hi Prasad,
> >
> > On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad  
> > wrote:
> >>
> >> Hi Glass,
> >>
> >>> -Original Message-
> >>> From: Simon Glass 
> >>> Sent: Wednesday, August 7, 2024 3:21 AM
> >>> To: Kummari, Prasad 
> >>> Cc: u-boot@lists.denx.de; git (AMD-Xilinx) ; Simek, 
> >>> Michal
> >>> ; Abbarapu, Venkatesh
> >>> ; g...@xilinx.com;
> >>> ja...@amarulasolutions.com; n-fran...@ti.com; d-g...@ti.com
> >>> Subject: Re: [PATCH] cmd: sf: prevent overwriting the reserved memory
> >>>
> >>> Caution: This message originated from an External Source. Use proper
> >>> caution when opening attachments, clicking links, or responding.
> >>>
> >>>
> >>> Hi Prasad,
> >>>
> >>> On Tue, 6 Aug 2024 at 06:08, Prasad Kummari  
> >>> wrote:
> 
>  Added LMB API to prevent SF command from overwriting reserved memory
>  areas. The current SPI code does not use LMB APIs for loading data
>  into memory addresses. To resolve this, LMB APIs were added to check
>  the load address of an SF command and ensure it does not overwrite
>  reserved memory addresses. Similar checks are used in TFTP, serial
>  load, and boot code to prevent overwriting reserved memory.
> >>>
> >>> The SPI flash may be used to load other things, not just an OS. What 
> >>> is your
> >>> use case or problem here?
> >>
> >> [Prasad]:  We have observed that SF command can overwrite the reserved 
> >> area without throwing any errors or warnings.
> >> This issue was noticed when the TF-A area is reserved in the 
> >> Device Tree at address 0xf00. The sf command is
> >> corrupting the reserved area,  and U-Boot relocation address too.
> >>
> >> EX: TF-A reserved at ddr address 0xf00
> >>
> >>  Versal NET> sf read 0x0f00 0x0 0x100 > 
> >> Overwriting reserved area.
> >>  device 0 offset 0x0, size 0x100
> >>  SF: 256 bytes @ 0x0 Read: OK
> >>
> >> U-boot relocation address relocaddr   = 0x7fec2000
> >>
> >>  Versal NET> sf write 0x77ec2000 0x0 0x100   --> 
> >> Overwriting reserved area.
> >>  device 0 offset 0x0, size 0x100
> >>  SF: 256 bytes @ 0x0 Written: OK
> >
> > Yes. There are many things which can overwrite memory, e.g. the mw
> > command. It is a boot loader so this is normal.
> >
> > What image are you loading here?
> 
>  In spi boot it can be Kernel/rootfs but at the end of day it doesn't 
>  really matter.
> >>>
> >>> OK, in that case yes it should use lmb. That was the question I was
> >>> trying to understand.
> >>>
> 
>  We have protection for srec, fs load, tftp and wget already.
> 
>  c6855195e4b4 ("loads: Block writes into LMB reserved areas of U-Boot")
>  aa3c609e2be5 ("fs: prevent overwriting reserved memory")
>  a156c47e39ad ("tftp: prevent overwriting reserved memory")
>  04592adbdb99 ("net: wget: prevent overwriting reserved memory")
> 
>  And this is just +1 patch to protect sf command that it doesn't touch 
>  reserved
>  location.
>  The same code should be used for other commands(nand, usb, etc) which 
>  loading
>  block of data to memory because all of them shouldn't rewrite reserved 
>  memory.
> 
>  In connection to mw/mtest/etc command protection can be also done but 
>  not sure
>  if this is useful because you normally not using them for booting.
> >>>
> >>> Exactly.
> >>>
> >>> I am hoping that we can pull SPI flash into bootstd...has anyone
> >>> looked at that? Are you using scripts or is there a special bootmeth?
> >>
> >> We didn't find this issue in connection to boot. As I wrote in another 
> >> reply we
> >> found it via spi testcases where TF-A was placed lower in DDR and test 
> >> overwrite
> >> it without any other evidence. Part of the reason is that protection units 
> >> are
> >> not enabled to protect secure FW.
> >
> > Do you mean the sandbox test test/dm/sf.c ? Or something else? If the
> > former, then we could mark dm_test_spi_flash() with CONFIG_SANDBOX
>
> pytest one and I think it was this one.
> https://github.com/Xilinx/u-boot-xlnx/blob/master/test/py/tests/test_spi.py
>
> Love is working on sending this test upstream as he did with others.

OK. But why is TF-A low in RAM? We really need to have a think about
this TF-A thing. This is the second pro

Re: [PATCH 23/40] lmb: add a flags parameter to the API's

[Simon Glass]

Hi Sughosh,

On Fri, 9 Aug 2024 at 02:25, Sughosh Ganu  wrote:
>
> On Thu, 8 Aug 2024 at 19:58, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Wed, 7 Aug 2024 at 00:32, Sughosh Ganu  wrote:
> > >
> > > On Wed, 7 Aug 2024 at 03:21, Simon Glass  wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > On Mon, 5 Aug 2024 at 05:55, Sughosh Ganu  
> > > > wrote:
> > > > >
> > > > > On Mon, 29 Jul 2024 at 20:56, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Sughosh,
> > > > > >
> > > > > > On Mon, 29 Jul 2024 at 02:40, Sughosh Ganu 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, 26 Jul 2024 at 05:02, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Sughosh,
> > > > > > > >
> > > > > > > > On Wed, 24 Jul 2024 at 00:04, Sughosh Ganu 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Add a flags parameter to the LMB API functions. The parameter 
> > > > > > > > > can then
> > > > > > > > > be used to pass any other type of reservations or allocations 
> > > > > > > > > needed
> > > > > > > > > by the callers. These will be used in a subsequent set of 
> > > > > > > > > changes for
> > > > > > > > > allocation requests coming from the EFI subsystem.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > > ---
> > > > > > > > > Changes since rfc: New patch
> > > > > > > > >
> > > > > > > > >  arch/arm/mach-apple/board.c   |  17 ++--
> > > > > > > > >  arch/arm/mach-snapdragon/board.c  |   2 +-
> > > > > > > > >  arch/arm/mach-stm32mp/dram_init.c |   4 +-
> > > > > > > > >  arch/powerpc/cpu/mpc85xx/mp.c |   2 +-
> > > > > > > > >  arch/powerpc/lib/bootm.c  |   2 +-
> > > > > > > > >  board/xilinx/common/board.c   |   4 +-
> > > > > > > > >  boot/bootm.c  |   5 +-
> > > > > > > > >  boot/image-board.c|  15 ++-
> > > > > > > > >  boot/image-fdt.c  |  15 +--
> > > > > > > > >  cmd/booti.c   |   2 +-
> > > > > > > > >  cmd/bootz.c   |   2 +-
> > > > > > > > >  cmd/load.c|   4 +-
> > > > > > > > >  drivers/iommu/apple_dart.c|   6 +-
> > > > > > > > >  drivers/iommu/sandbox_iommu.c |   6 +-
> > > > > > > > >  fs/fs.c   |   2 +-
> > > > > > > > >  include/lmb.h |  23 ++---
> > > > > > > > >  lib/lmb.c |  48 --
> > > > > > > > >  test/lib/lmb.c| 150 
> > > > > > > > > +++---
> > > > > > > > >  18 files changed, 150 insertions(+), 159 deletions(-)
> > > > > > > >
> > > > > > > > This negates any code-size advantage of dropping the lmb 
> > > > > > > > parameter.
> > > > > > > >
> > > > > > > > All of these are LMB_NONE. Can we have a separate function (e.g.
> > > > > > > > lmb_alloc_type()) for when we actually need to specify the type?
> > > > > > >
> > > > > > > We will be passing different values when we call the LMB API's 
> > > > > > > from
> > > > > > > the EFI allocation function. This is only adding a parameter to 
> > > > > > > the
> > > > > > > allocation API's, which I believe is better than adding separate
> > > > > > > functions which take a flag parameter only to be called from the 
> > > > > > > EFI
> > > > > > > subsystem.
> > > > > >
> > > > > > No i believe it is worse, unless there are a lot of such functions.
> > > > > > The flags are a special case, not the common case.
> > > > >
> > > > > I have done some size impact tests on the two scenarios, one where we
> > > > > have a common set of lmb allocation API functions, with an added flags
> > > > > parameter, and second where we have separate API's to be called from
> > > > > the EFI memory module. I have put out the results of the size impact
> > > > > [1].
> > > > >
> > > > > You will see that with common API's, we are not losing much even on
> > > > > boards with EFI_LOADER disabled. But otoh, on boards which have
> > > > > EFI_LOADER enabled, the gains are pretty significant. I believe we
> > > > > should reconsider using a common LMB API with the flags parameter.
> > > >
> > > > Thanks for looking at it.
> > > >
> > > > Did you do special versions of just lmb_alloc() and lmb_add() which
> > > > call the flags versions? It seems that there is no size advantage with
> > > > EFI_LOADER and only a small one with !EFI_LOADER. Can you please point
> > > > me to the code?
> > >
> > > For the separate API version, I introduced new versions
> > > lmb_alloc_flags(), lmb_alloc_base_flags(), lmb_alloc_addr_flags() and
> > > lmb_free_flags(), which are being called from the EFI memory module. I
> > > have pushed the two branches [1] [2] on my github. Please take a look.
> > >
> > > Btw, both these branches are based on your v5 of the alist patches,
> > > and also incorporate the stack based implementation for running the
> > > lmb tests. So except for either having common API's, or not, there are
> > > no other differences between the two

Re: [PATCH] env: remove vars that are not in default env

[Simon Glass]

Hi Ravi,

On Fri, 9 Aug 2024 at 09:38, Ravi Minnikanti  wrote:
>
>
> current env_set_default_vars() doesn't delete
> var that are not in the imported env. hashtable
> removes vars that are not in the imported
> env but present in the current env only if H_NOCLEAR
> flag is not set.
>
> This change is to avoid passing H_NOCLEAR flag if
> specific vars are passed to env_set_default_vars()
>
> Test:
>
> Without this change:
> Marvell>> env default boot_mode
> Marvell>>
>
> With the change:
> Marvell>> env default boot_mode
> WARNING: 'boot_mode' not in imported env, deleting it!
>
> Signed-off-by: rminnikanti 
> ---
>  env/common.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)

Could you add to usage/environment.rst and also update the tests for
this - test/env/ - I suppose your patch fixes a bug, but it is hard to
figure out what it is supposed to do from the docs.

See for example dm_test_acpi_cmd_set() for how to check output from a command.

>
> diff --git a/env/common.c b/env/common.c
> index 8d47d72605..2f783e3a69 100644
> --- a/env/common.c
> +++ b/env/common.c
> @@ -401,7 +401,15 @@ int env_set_default_vars(int nvars, char * const vars[], 
> int flags)
>  * Special use-case: import from default environment
>  * (and use \0 as a separator)
>  */
> -   flags |= H_NOCLEAR | H_DEFAULT;
> +
> +   /*
> +* When vars are passed remove variables that are not in
> +* the default environment.
> +*/
> +   if (!nvars)
> +   flags |= H_NOCLEAR;
> +
> +   flags |= H_DEFAULT;
> return himport_r(&env_htab, default_environment,
> sizeof(default_environment), '\0',
> flags, 0, nvars, vars);
> --
> 2.25.1
Regards,
Simon

Re: [PATCH v3 19/19] CI: Allow running tests on sjg lab

[Simon Glass]

Hi Tom,

On Tue, 25 Jun 2024 at 06:30, Simon Glass  wrote:
>
> Hi,
>
> On Mon, 24 Jun 2024 at 19:01, Tom Rini  wrote:
> >
> > On Mon, Jun 24, 2024 at 04:56:02PM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi Simon
> > >
> > > On Mon, Jun 24, 2024 at 2:52 PM Andrejs Cainikovs
> > >  wrote:
> > > >
> > > > On Sun, Jun 23, 2024 at 02:32:13PM -0600, Simon Glass wrote:
> > > > > Add a way to run tests on a real hardware lab. This is in the very 
> > > > > early
> > > > > experimental stages. There are only 23 boards and 3 of those are 
> > > > > broken!
> > > > > (bob, ff3399, samus). A fourth fails due to problems with the TPM 
> > > > > tests.
> > > > >
> > > > > To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
> > > > >
> > > > >git push -o ci.variable="SJG_LAB=1" dm HEAD:try
> > > > >
> > > > > This relies on the two previous series targeted at -next as well as 
> > > > > the
> > > > > bugfix series for -master
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > >
> > > > Reviewed-by: Andrejs Cainikovs 
> > > >
> > >
> > > Do you have documentation on how to set it? We would like to do in our
> > > company too
> >
> > I _think_ from some talking with Simon before the biggest sticking point
> > might be changes needed on the labgrid side of things. However, that
> > might also be most easily remedied if there's a few people showing up in
> > the GitHub issue(s) showing interest in getting changes made/merged and
> > to use the overall feature.
>
> The documentation is in the PR [1] mostly in the last commit [2].
>
> Yes it would really help for you to try it out and comment on the PR.
> I may end up splitting it into a few separate PRs, but code review on
> the project is very limited, from what I have seen so far. You will
> see an example of my lab (devices and environment file).
>
> I also have a few minor updates to the PR which I just uploaded, to
> work on top of the grpc branch and to support QEMU.

Just to mention that I updated the Labgrid integration to support
beagleplay (which as you know combines the U-Boot builds for two
boards). It resulted in no changes at all to this series.

So perhaps this series can be reviewed and some of it applied?

Documentation is below.



>
> [1] https://github.com/labgrid-project/labgrid/pull/1411
> [2] 
> https://github.com/labgrid-project/labgrid/pull/1411/commits/c4b13af0e6169228c9adef03d4b66401201edd23

Regards,
Simon

Re: [PATCH v2 0/3] efi: Start tidying up memory management

[Simon Glass]

Hi,

On Thu, 1 Aug 2024 at 11:36, Simon Glass  wrote:
>
> We have been discussing the state of EFI memory management for some
> years so I thought it might be best to send a short series showing some
> of the issues we have talked about.
>
> This one just deals with memory allocation. It updates EFI to use
> U-Boot memory allocation for the pool where possible. Most functions use
> that anyway and it is much more efficient. It also avoids allocating
> things 'in space' in conflict with the loaded images.
>
> For v2 I have dropped patches which are not germane to the main idea.
>
> Note that this series is independent from Sugosh's lmb series[1],
> although I believe it will point the way to simplifying some of the
> later patches in that series.
>
> Overall, some issues which should be resolved in future are:
> - allocation inconsistency, e.g. efi_add_protocol() uses malloc() but
>   efi_dp_dup() does not (this series makes a start)
> - change efi_bl_init() to register events later, when the devices are
>   actually used
> - rather than efi_set_bootdev(), provide a bootstd way to take note of
>   the device images came from and allow EFI to query that when needed
> - EFI_LOADER_BOUNCE_BUFFER - can use U-Boot bounce buffers?
>
> Minor questions on my mind:
> - is unaligned access useful? Is there a performance penalty?
> - API confusion about whether something is an address or a pointer
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=416441
>
> Changes in v2:
> - Drop patch 'Show more information in efi index'
> - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
> - Add the word 'warning', use log_warning() and show the end address
> - Reorder patches a little
>
> Simon Glass (3):
>   efi: Allow use of malloc() for the EFI pool
>   efi: Convert device_path allocation to use malloc()
>   efi: Show the location of the bounce buffer
>
>  common/dlmalloc.c|   7 ++
>  include/efi_loader.h |  18 
>  include/malloc.h |   7 ++
>  lib/efi_loader/efi_bootbin.c |  11 +++
>  lib/efi_loader/efi_device_path.c |  43 +
>  lib/efi_loader/efi_device_path_to_text.c |   2 +-
>  lib/efi_loader/efi_memory.c  | 110 +--
>  7 files changed, 148 insertions(+), 50 deletions(-)
>
> --
> 2.34.1
>

Are there any comments on this series, please?

Regards,
Simon

Re: [PATCH v2 1/3] ext4: Fix integer overflow in ext4fs_read_symlink()

[Heinrich Schuchardt]

On 09.08.24 11:54, Richard Weinberger wrote:

While zalloc() takes a size_t type, adding 1 to the le32 variable
will overflow.
A carefully crafted ext4 filesystem can exhibit an inode size of 0x
and as consequence zalloc() will do a zero allocation.

Later in the function the inode size is again used for copying data.
So an attacker can overwrite memory.

Avoid the overflow by using the __builtin_add_overflow() helper.

Signed-off-by: Richard Weinberger 
---
  fs/ext4/ext4_common.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 52152a2295..36999b608f 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2181,13 +2181,18 @@ static char *ext4fs_read_symlink(struct ext2fs_node 
*node)
struct ext2fs_node *diro = node;
int status;
loff_t actread;
+   size_t alloc_size;

if (!diro->inode_read) {
status = ext4fs_read_inode(diro->data, diro->ino, &diro->inode);
if (status == 0)
return NULL;
}
-   symlink = zalloc(le32_to_cpu(diro->inode.size) + 1);
+
+   if (__builtin_add_overflow(le32_to_cpu(diro->inode.size), 1, 
&alloc_size))
+   return NULL;


Thank you for pointing at the problematic code.

You are calling __builtin_add_overflow(int, int, size_t *).

__builtin_add_overflow() is not defined in the C-standard.

Is there any well defined behavior for this on systems where size_t has
more bits than int?

I could imagine implementations just copying an int to the first 32 bits
of alloc_size and leaving the other bits untouched.

Hopefully your C-compiler simply refuses to compile this code.

I would prefer to stick to standard C:

alloc_size = le32_to_cpu(diro->inode.size) + 1UL;
if (!alloc_size)
return NULL;

Here an overflow can only occur on 32bit systems.

Best regards

Heinrich


+
+   symlink = zalloc(alloc_size);
if (!symlink)
return NULL;

Re: [PATCH v2 1/3] ext4: Fix integer overflow in ext4fs_read_symlink()

[Richard Weinberger]

Heinrich,

Am Freitag, 9. August 2024, 18:13:27 CEST schrieb 'Heinrich Schuchardt' via 
upstream:
> Thank you for pointing at the problematic code.
> 
> You are calling __builtin_add_overflow(int, int, size_t *).
> 
> __builtin_add_overflow() is not defined in the C-standard.
> 
> Is there any well defined behavior for this on systems where size_t has
> more bits than int?

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html says:

Built-in Function: bool __builtin_add_overflow (type1 a, type2 b, type3 *res)

These built-in functions promote the first two operands into infinite precision 
signed type and perform addition on those promoted operands.
The result is then cast to the type the third pointer argument points to and 
stored there.
If the stored result is equal to the infinite precision result, the built-in 
functions return false, otherwise they return true.
As the addition is performed in infinite signed precision, these built-in 
functions have fully defined behavior for all argument values. 

So, I don't really see a problem here.

> I could imagine implementations just copying an int to the first 32 bits
> of alloc_size and leaving the other bits untouched.
> 
> Hopefully your C-compiler simply refuses to compile this code.
> 
> I would prefer to stick to standard C:
> 
> alloc_size = le32_to_cpu(diro->inode.size) + 1UL;
> if (!alloc_size)
>   return NULL;
> 
> Here an overflow can only occur on 32bit systems.

In this specific case we could avoid the builtis, yes.
But I prefer using __builtin_add_overflow() as it offers a generic
and bullet prove mechanism to avoid these kind of bugs.

It's not that they are something new and funky.
Other projects use them since ages.

Thanks,
//richard

-- 
​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT
UID/VAT Nr: ATU 66964118 | FN: 374287y

Re: [PATCH v2 1/3] efi: Allow use of malloc() for the EFI pool

[Heinrich Schuchardt]

On 01.08.24 19:36, Simon Glass wrote:

This API call is intended for allocating small amounts of memory,
similar to malloc(). The current implementation rounds up to whole pages
which can waste large amounts of memory. It also implements its own
malloc()-style header on each block.

For certain allocations (those of type EFI_BOOT_SERVICES_DATA) we can
use U-Boot's built-in malloc() instead, at least until the app starts.
This avoids poluting the memory space with blocks of data which may
interfere with boot scripts, etc.

Once the app has started, there is no advantage to using malloc(), since
it doesn't matter what memory is used: everything is under control of
the EFI subsystem. Also, using malloc() after the app starts might
result in running of memory, since U-Boot's malloc() space is typically
quite small.

In fact, malloc() is already used for most EFI-related allocations, so
the impact of this change is fairly small.

One side effect is that this seems to be showing up some bugs in the
EFI code, since the malloc() pool becomes corrupted when running some of
the tests.

This has likely crept in due to the very large gaps between allocations
(around 4KB), which provides a lot of leeway when the allocation size is
too small. Work around this by increasing the size for now, until these
(presumed) bugs are located.

Signed-off-by: Simon Glass 
---

(no changes since v1)

  common/dlmalloc.c|   7 +++
  include/efi_loader.h |  18 ++
  include/malloc.h |   7 +++
  lib/efi_loader/efi_bootbin.c |   2 +
  lib/efi_loader/efi_memory.c  | 110 ++-
  5 files changed, 117 insertions(+), 27 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 62e8557daa7..0bc77395035 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -613,6 +613,13 @@ void mem_malloc_init(ulong start, ulong size)
  #endif
  }

+bool malloc_check_in_range(void *ptr)
+{
+   ulong val = (ulong)ptr;
+
+   return val >= mem_malloc_start && val < mem_malloc_end;
+}
+
  /* field-extraction macros */

  #define first(b) ((b)->fd)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f84852e384f..31899bef99e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -796,6 +796,24 @@ int efi_disk_probe(void *ctx, struct event *event);
  int efi_disk_remove(void *ctx, struct event *event);
  /* Called by board init to initialize the EFI memory map */
  int efi_memory_init(void);
+
+/**
+ * enum efi_alloc_flags - controls EFI memory allocation
+ *
+ * @EFIAF_USE_MALLOC: Use malloc() pool for pool allocations of type
+ * EFI_BOOT_SERVICES_DATA, otherwise use page allocation
+ */
+enum efi_alloc_flags {
+   EFIAF_USE_MALLOC= BIT(0),
+};
+
+/**
+ * efi_set_alloc() - Set behaviour of EFI memory allocation
+ *
+ * @flags: new value for allocation flags (see enum efi_alloc_flags)
+ */
+void efi_set_alloc(int flags);
+
  /* Adds new or overrides configuration table entry to the system table */
  efi_status_t efi_install_configuration_table(const efi_guid_t *guid, void 
*table);
  /* Sets up a loaded image */
diff --git a/include/malloc.h b/include/malloc.h
index 07d3e90a855..a64f117e2f2 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -983,6 +983,13 @@ extern ulong mem_malloc_brk;

  void mem_malloc_init(ulong start, ulong size);

+/**
+ * malloc_check_in_range() - Check if a pointer is within the malloc() region
+ *
+ * Return: true if within malloc() region
+ */
+bool malloc_check_in_range(void *ptr);
+
  #ifdef __cplusplus
  };  /* end of extern "C" */
  #endif
diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index a87006b3c0e..5bb0fdcf75d 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -201,6 +201,8 @@ efi_status_t efi_binary_run(void *image, size_t size, void 
*fdt)
  {
efi_status_t ret;

+   efi_set_alloc(0);
+
/* Initialize EFI drivers */
ret = efi_init_obj_list();
if (ret != EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index c6f1dd09456..3c3d05eef94 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -24,6 +24,14 @@ DECLARE_GLOBAL_DATA_PTR;
  /* Magic number identifying memory allocated from pool */
  #define EFI_ALLOC_POOL_MAGIC 0x1fe67ddf6491caa2

+/* Flags controlling EFI memory-allocation - see enum efi_alloc_flags */
+static int alloc_flags;
+
+void efi_set_alloc(int flags)
+{
+   alloc_flags = flags;
+}
+
  efi_uintn_t efi_memory_map_key;

  struct efi_mem_list {
@@ -57,8 +65,12 @@ void *efi_bounce_buffer;
   * The checksum calculated in function checksum() is used in FreePool() to 
avoid
   * freeing memory not allocated by AllocatePool() and duplicate freeing.
   *
- * EFI requires 8 byte alignment for pool allocations, so we can
- * prepend each allocation with these header fields.
+ * EFI requires 8-byte alignment for pool allocations, so we can prepend 

[PATCH v4] config: Add 'update_bootimg' command to update flash.bin on Phytec's imx8mm

[Lukasz Majewski]

This command allows easy update on SD card or eMMC of the flash.bin
generated (with binman) during u-boot build.

Signed-off-by: Lukasz Majewski 
---
Changes for v2:
- Remove 'update_mmc_part' variable
- Change path for hostname
- Use full version of dhcp command (${loadaddr} added)

Changes for v3:
- Remove +1 when calculating the size of binary to be written

Changes for v4:
- Replace ${hostname} with ${update_filepath}
---
 include/configs/phycore_imx8mm.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/configs/phycore_imx8mm.h b/include/configs/phycore_imx8mm.h
index dd7cfdba52..0910ae2d87 100644
--- a/include/configs/phycore_imx8mm.h
+++ b/include/configs/phycore_imx8mm.h
@@ -29,6 +29,14 @@
"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
"mmcpart=1\0" \
"mmcroot=2\0" \
+   "update_offset=0x42\0" \
+   "update_filename=flash.bin\0" \
+   "update_bootimg="   \
+   "mmc dev ${mmcdev} ; "  \
+   "if dhcp ${loadaddr} ${update_filepath}/${update_filename} ; 
then " \
+   "setexpr fw_sz ${filesize} / 0x200 ; "  /* SD block size */ \
+   "mmc write ${loadaddr} ${update_offset} ${fw_sz} ; "\
+   "fi\0" \
"mmcautodetect=yes\0" \
"mmcargs=setenv bootargs console=${console} " \
"root=/dev/mmcblk${mmcdev}p${mmcroot} rootwait rw\0" \
-- 
2.39.2

Re: [PATCH] cmd: add a fetch utility

[Caleb Connolly]

Hi Simon,

On 09/08/2024 03:55, Simon Glass wrote:

Hi Caleb,

On Thu, 8 Aug 2024 at 10:32, Caleb Connolly > wrote:

 >
 > While U-Boot does a pretty good job at printing information at startup
 > about what hardware it's running on, it can be hard to take pretty
 > pictures of this to show off on the internet (by far the most
 > important aspect of porting a device in 2024!).
 >
 > Add a small utility "ufetch" for displaying some information about 
U-Boot and
 > the hardware it's running on in a similar fashion to the popular 
neofetch tool

 > for *nix's [1].
 >
 > While the output is meant to be useful, it should also be pleasing to 
look at

 > and look good in screenshots. The ufetch command brings this to U-Boot,
 > featuring a colorful ASCII art version of the U-Boot logo and a fancy 
layout.

 >
 > Finally, tireless device porters can properly show off their hard 
work and get

 > the internet points they so deserve!
 >
 > Not everything is fully supported yet, but this seemed good enough 
for initial
 > inclusion. Only one MMC device is detected, and other than SCSI other 
storage

 > devices aren't supported.
 >
 > [1]: https://en.wikipedia.org/wiki/Neofetch 


 >
 > Signed-off-by: Caleb Connolly >

 > ---
 > Ephemeral demo image: https://0x0.st/XVUa.png 
 > ---
 >  cmd/Kconfig  |   7 ++
 >  cmd/Makefile |   1 +
 >  cmd/ufetch.c | 201 +++
 >  3 files changed, 209 insertions(+)
 >  create mode 100644 cmd/ufetch.c

Very cute!

 >
 > diff --git a/cmd/Kconfig b/cmd/Kconfig
 > index 978f44eda426..70acb5727b04 100644
 > --- a/cmd/Kconfig
 > +++ b/cmd/Kconfig
 > @@ -175,8 +175,15 @@ config CMD_CPU
 >           number of CPUs, type (e.g. manufacturer, architecture, 
product or

 >           internal name) and clock frequency. Other information may be
 >           available depending on the CPU driver.
 >
 > +config CMD_UFETCH
 > +       bool "U-Boot fetch"

How about default y if SANDBOX so that this gets built for that. You 
should also add doc/ and test/ for the command (although the test can be 
very basic).


I was really aiming for cmd/2048.c levels of expectation and usability 
here, not to make this a rugged part of U-Boot's feature set (if someone 
else would like to go the extra mile they're certainly welcome to).


Making it default y for sandbox so we can at least make sure it compiles 
sounds reasonable though.


 > +       depends on BLK
 > +       help
 > +         Fetch utility for U-Boot (akin to neofetch). Prints information
 > +         about U-Boot and the board it is running on in a pleasing 
format.

 > +
 >  config CMD_FWU_METADATA
 >         bool "fwu metadata read"
 >         depends on FWU_MULTI_BANK_UPDATE
 >         help
 > diff --git a/cmd/Makefile b/cmd/Makefile
 > index 87133cc27a8a..ffb04c8f2e0a 100644
 > --- a/cmd/Makefile
 > +++ b/cmd/Makefile
 > @@ -53,8 +53,9 @@ obj-$(CONFIG_CMD_CONSOLE) += console.o
 >  obj-$(CONFIG_CMD_CPU) += cpu.o
 >  obj-$(CONFIG_CMD_DATE) += date.o
 >  obj-$(CONFIG_CMD_DEMO) += demo.o
 >  obj-$(CONFIG_CMD_DM) += dm.o
 > +obj-$(CONFIG_CMD_UFETCH) += ufetch.o
 >  obj-$(CONFIG_CMD_SOUND) += sound.o
 >  ifdef CONFIG_POST
 >  obj-$(CONFIG_CMD_DIAG) += diag.o
 >  endif
 > diff --git a/cmd/ufetch.c b/cmd/ufetch.c
 > new file mode 100644
 > index ..f7374eb2e364
 > --- /dev/null
 > +++ b/cmd/ufetch.c
 > @@ -0,0 +1,201 @@
 > +// SPDX-License-Identifier: GPL-2.0
 > +
 > +/* Small "fetch" utility for U-Boot */

Isn't it a command, rather than a utility? I think of a utility as a 
program I run.


I feel like you could ask 5 different people about this and get 5 
different answers. As a native british english speaker I would view 
"utilities" as a subset of "commands" in this context. This isn't a high 
effort contribution for me so I'm really fine with whatever.


 > +
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 

Please check [1]


Sure, I'll order these alphabetically.


 > +
 > +DECLARE_GLOBAL_DATA_PTR;
 > +
 > +#define LINE_WIDTH 40
 > +#define BLUE "\033[38;5;4m"
 > +#define YELLOW "\033[38;5;11m"
 > +#define BOLD "\033[1m"
 > +#define RESET "\033[0m"
 > +static const char *logo_lines[] = {
 > +       BLUE BOLD "                  ..::..                   ",
 > +       BLUE BOLD "             ...::...              ",
 > +       BLUE BOLD "          ..::..           ",
 > +       BLUE BOLD "        ..:::.....         ",
 > +       BLUE BOLD "      ...::.       ",
 > +       BLUE BOLD "    .::.:::" YELLOW "=*%#*" BLUE 
"::.::.     ",
 > +       BLUE BOLD "   .:." YELLOW "*%%*-" BLUE 
":::.

Re: [PATCH] cmd: add a fetch utility

[Caleb Connolly]

On 09/08/2024 08:18, Heinrich Schuchardt wrote:



Am 8. August 2024 18:24:24 MESZ schrieb Caleb Connolly 
:

While U-Boot does a pretty good job at printing information at startup
about what hardware it's running on, it can be hard to take pretty
pictures of this to show off on the internet (by far the most
important aspect of porting a device in 2024!).

Add a small utility "ufetch" for displaying some information about U-Boot and
the hardware it's running on in a similar fashion to the popular neofetch tool
for *nix's [1].

While the output is meant to be useful, it should also be pleasing to look at
and look good in screenshots. The ufetch command brings this to U-Boot,
featuring a colorful ASCII art version of the U-Boot logo and a fancy layout.

Finally, tireless device porters can properly show off their hard work and get
the internet points they so deserve!

Not everything is fully supported yet, but this seemed good enough for initial
inclusion. Only one MMC device is detected, and other than SCSI other storage
devices aren't supported.



This command is not very generic. E.g. it supports SCSI drives but not SATA. 
Many boards have eMMC and SD-card. This lks more ike an RFC tan something ready 
to merge.


Honestly it didn't even occur to me to send an RFC since this is purely 
a vanity thing...


I'll make it generic over UCLASS_BLK if possible for the next revision.


Why don't you use a script or an EFI program to print whatever information you 
need?


Well , then you'd need to have a way to load the script or EFI binary, 
which might not be possible for an early U-Boot port which doesn't have 
storage support yet (or at least, be a bunch of effort).


The only motivation to have this in U-Boot is really because

a) it's cute
b) it motivates "reward oriented" people like myself to get U-Boot 
booting on new/interesting devices because now it can be really easily 
shown off.


Maybe it's a cynical take, but I think stuff like this really has the 
potential to get more folks interested. Nobody likes doing the invisible 
background work, so why not bring some visibility to things?


Assuming I did a bad job at conveying my intent in the patch 
description: the point here is not to convey useful debugging 
information to developers, it's to show off, look pretty, and be 
amusing. Plenty of other U-Boot commands can convey information, this 
one is more like the 2048 port.




[1]: https://en.wikipedia.org/wiki/Neofetch

Signed-off-by: Caleb Connolly 
---
Ephemeral demo image: https://0x0.st/XVUa.png
---
cmd/Kconfig  |   7 ++
cmd/Makefile |   1 +
cmd/ufetch.c | 201 +++
3 files changed, 209 insertions(+)
create mode 100644 cmd/ufetch.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 978f44eda426..70acb5727b04 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -175,8 +175,15 @@ config CMD_CPU
  number of CPUs, type (e.g. manufacturer, architecture, product or
  internal name) and clock frequency. Other information may be
  available depending on the CPU driver.

+config CMD_UFETCH
+   bool "U-Boot fetch"
+   depends on BLK
+   help
+ Fetch utility for U-Boot (akin to neofetch). Prints information
+ about U-Boot and the board it is running on in a pleasing format.
+
config CMD_FWU_METADATA
bool "fwu metadata read"
depends on FWU_MULTI_BANK_UPDATE
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 87133cc27a8a..ffb04c8f2e0a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -53,8 +53,9 @@ obj-$(CONFIG_CMD_CONSOLE) += console.o
obj-$(CONFIG_CMD_CPU) += cpu.o
obj-$(CONFIG_CMD_DATE) += date.o
obj-$(CONFIG_CMD_DEMO) += demo.o
obj-$(CONFIG_CMD_DM) += dm.o
+obj-$(CONFIG_CMD_UFETCH) += ufetch.o
obj-$(CONFIG_CMD_SOUND) += sound.o
ifdef CONFIG_POST
obj-$(CONFIG_CMD_DIAG) += diag.o
endif
diff --git a/cmd/ufetch.c b/cmd/ufetch.c
new file mode 100644
index ..f7374eb2e364
--- /dev/null
+++ b/cmd/ufetch.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* Small "fetch" utility for U-Boot */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define LINE_WIDTH 40
+#define BLUE "\033[38;5;4m"
+#define YELLOW "\033[38;5;11m"
+#define BOLD "\033[1m"
+#define RESET "\033[0m"
+static const char *logo_lines[] = {
+   BLUE BOLD "  ..::..   ",
+   BLUE BOLD " ...::...  ",
+   BLUE BOLD "  ..::..   ",
+   BLUE BOLD "..:::..... ",
+   BLUE BOLD "  ...::.   ",
+   BLUE BOLD ".::.:::" YELLOW "=*%#*" BLUE "::.::.  
   ",
+   BLUE BOLD "   .:." YELLOW "*%%*-" BLUE ":::. 
   ",
+   BLUE BOLD " 

Re: [PATCH v2 3/3] efi: Show the location of the bounce buffer

[Heinrich Schuchardt]

On 01.08.24 19:36, Simon Glass wrote:

The EFI_LOADER_BOUNCE_BUFFER feature was added many years ago. It is not
clear whether it is still needed, but 24 boards (lx2160ardb_tfa_stmm,
lx2162aqds_tfa_SECURE_BOOT and the like) use it.

This feature uses EFI page allocation to create a 64MB buffer 'in space'
without any knowledge of where boards intend to load their images. This
may result in image corruption or other problems.

For example, if the feature is enabled on qemu_arm64 it puts the EFI
bounce buffer at 1045MB, with the kernel at 1028MB and the ramdisk at
1088MB. The kernel is probably smaller than 27MB but the buffer does
overlap the ramdisk.

The solution is probably to use BOUNCE_BUFFER instead, with the EFI
version being dropped. For now, show the address of the EFI bounce
buffer so people have a better chance to detect the problem.

Note: I avoided converting this #ifdef to use IS_ENABLED() since I hope
that the feature may be removed.


EFI_BLOCK_IO_PROTOCOL.ReadBlocks() and
EFI_BLOCK_IO_PROTOCOL.WriteBlocks() are expected to block until all
bytes are transferred.

The complete file transfer is chunked according to the size of the EFI
bounce buffer.

Taking care of alignment issues would best handled by the block uclass.

When CONFIG_BOUNCE_BUFFER=y, bounce_buffer_start_extalign() uses
memalign() which limits the bounce buffer to available malloc() memory
(typically < 2 MiB).

I cannot see how blk_read() with CONFIG_BOUNCE_BUFFER=y will work if
blkcnt * desc->blksz is greater than the available malloc memory.

Shouldn't the block uclass support chunking?

Best regards

Heinrich



Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop patch 'Show more information in efi index'
- Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
- Add the word 'warning', use log_warning() and show the end address
- Reorder patches a little

  lib/efi_loader/efi_bootbin.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index 5bb0fdcf75d..9779dc09b5e 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -211,6 +211,15 @@ efi_status_t efi_binary_run(void *image, size_t size, void 
*fdt)
return -1;
}

+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+   /*
+* Add a warning about this buffer, since it may conflict with other
+* things
+*/
+   log_warning("Warning: EFI bounce buffer %p-%p\n", efi_bounce_buffer,
+   efi_bounce_buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
+#endif
+
ret = efi_install_fdt(fdt);
if (ret != EFI_SUCCESS)
return ret;

Re: [PATCH] MAINTAINERS: Update path for U-Boot environment variables YAML

[Srinivas Kandagatla]

On Thu, 08 Aug 2024 07:57:10 +0200, Rafał Miłecki wrote:
> This file was moved to the layouts/ subdirectory.
> 
> 

Applied, thanks!

[1/1] MAINTAINERS: Update path for U-Boot environment variables YAML
  commit: f6d1cddd76b2da190462d84546e5202d3b2aa92b

Best regards,
-- 
Srinivas Kandagatla 

[PATCH 1/2] tqma6: Convert to PMIC and I2C driver model

[Fabio Estevam]

From: Fabio Estevam 

Currently, the power_init_board() function is not executed because
CONFIG_POWER_LEGACY is not selected.

Convert to PMIC driver model, which allows removing board I2C code in
favor of the I2C driver model.

Signed-off-by: Fabio Estevam 
---
 board/tq/tqma6/tqma6.c  | 61 +++--
 include/configs/tqma6.h |  8 --
 2 files changed, 10 insertions(+), 59 deletions(-)

diff --git a/board/tq/tqma6/tqma6.c b/board/tq/tqma6/tqma6.c
index 92142c10ae5a..02a2022c3c84 100644
--- a/board/tq/tqma6/tqma6.c
+++ b/board/tq/tqma6/tqma6.c
@@ -19,11 +19,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -48,10 +46,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define SPI_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
 
-#define I2C_PAD_CTRL   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
-   PAD_CTL_DSE_80ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
-
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -170,38 +164,6 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs)
 #endif
 #endif
 
-#if CONFIG_IS_ENABLED(SYS_I2C_LEGACY)
-static struct i2c_pads_info tqma6_i2c3_pads = {
-   /* I2C3: on board LM75, M24C64,  */
-   .scl = {
-   .i2c_mode = NEW_PAD_CTRL(MX6_PAD_GPIO_5__I2C3_SCL,
-I2C_PAD_CTRL),
-   .gpio_mode = NEW_PAD_CTRL(MX6_PAD_GPIO_5__GPIO1_IO05,
- I2C_PAD_CTRL),
-   .gp = IMX_GPIO_NR(1, 5)
-   },
-   .sda = {
-   .i2c_mode = NEW_PAD_CTRL(MX6_PAD_GPIO_6__I2C3_SDA,
-I2C_PAD_CTRL),
-   .gpio_mode = NEW_PAD_CTRL(MX6_PAD_GPIO_6__GPIO1_IO06,
- I2C_PAD_CTRL),
-   .gp = IMX_GPIO_NR(1, 6)
-   }
-};
-
-static void tqma6_setup_i2c(void)
-{
-   int ret;
-   /*
-* use logical index for bus, e.g. I2C1 -> 0
-* warn on error
-*/
-   ret = setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, &tqma6_i2c3_pads);
-   if (ret)
-   printf("setup I2C3 failed: %d\n", ret);
-}
-#endif
-
 int board_early_init_f(void)
 {
return tqma6_bb_board_early_init_f();
@@ -215,10 +177,6 @@ int board_init(void)
 #ifndef CONFIG_DM_SPI
tqma6_iomuxc_spi();
 #endif
-#if CONFIG_IS_ENABLED(SYS_I2C_LEGACY)
-   tqma6_setup_i2c();
-#endif
-
tqma6_bb_board_init();
 
return 0;
@@ -246,21 +204,22 @@ static const char *tqma6_get_boardname(void)
};
 }
 
-#if CONFIG_IS_ENABLED(POWER_LEGACY)
+#if CONFIG_IS_ENABLED(DM_PMIC)
 /* setup board specific PMIC */
 int power_init_board(void)
 {
-   struct pmic *p;
+   struct udevice *dev;
u32 reg, rev;
+   int ret;
 
-   power_pfuze100_init(TQMA6_PFUZE100_I2C_BUS);
-   p = pmic_get("PFUZE100");
-   if (p && !pmic_probe(p)) {
-   pmic_reg_read(p, PFUZE100_DEVICEID, ®);
-   pmic_reg_read(p, PFUZE100_REVID, &rev);
-   printf("PMIC: PFUZE100 ID=0x%02x REV=0x%02x\n", reg, rev);
-   }
+   ret = pmic_get("pmic@8", &dev);
+   if (ret < 0)
+   return 0;
+
+   reg = pmic_reg_read(dev, PFUZE100_DEVICEID);
+   rev = pmic_reg_read(dev, PFUZE100_REVID);
 
+   printf("PMIC:  PFUZE100 ID=0x%02x REV=0x%02x\n", reg, rev);
return 0;
 }
 #endif
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index 2da76f154313..b4a06a75c538 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -26,14 +26,6 @@
 
 #define TQMA6_SPI_FLASH_SECTOR_SIZESZ_64K
 
-/* I2C Configs */
-#define CFG_I2C_MULTI_BUS
-
-#if !defined(CONFIG_DM_PMIC)
-#define CFG_POWER_PFUZE100_I2C_ADDR0x08
-#define TQMA6_PFUZE100_I2C_BUS 2
-#endif
-
 /* MMC Configs */
 #define CFG_SYS_FSL_ESDHC_ADDR 0
 
-- 
2.34.1

[PATCH 2/2] tqma6: Do not print the board name twice

[Fabio Estevam]

From: Fabio Estevam 

Currently, the devicetree model as well as the board variant name
are shown:
...
Model: TQ TQMa6S/DL on MBa6x
Board: TQMa6DL on a MBa6x
...

Unselect the CONFIG_DISPLAY_BOARDINFO option so that the
board name is printed only once in board_late_init() instead.

Signed-off-by: Fabio Estevam 
---
 board/tq/tqma6/tqma6.c | 5 -
 configs/tqma6dl_mba6_mmc_defconfig | 1 +
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/board/tq/tqma6/tqma6.c b/board/tq/tqma6/tqma6.c
index 02a2022c3c84..445ce987b683 100644
--- a/board/tq/tqma6/tqma6.c
+++ b/board/tq/tqma6/tqma6.c
@@ -230,11 +230,6 @@ int board_late_init(void)
 
tqma6_bb_board_late_init();
 
-   return 0;
-}
-
-int checkboard(void)
-{
printf("Board: %s on a %s\n", tqma6_get_boardname(),
   tqma6_bb_get_boardname());
return 0;
diff --git a/configs/tqma6dl_mba6_mmc_defconfig 
b/configs/tqma6dl_mba6_mmc_defconfig
index be891d24537f..d0c5db65177c 100644
--- a/configs/tqma6dl_mba6_mmc_defconfig
+++ b/configs/tqma6dl_mba6_mmc_defconfig
@@ -17,6 +17,7 @@ CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="run mmcboot; run netboot; run panicboot"
 CONFIG_DEFAULT_FDT_FILE="imx6dl-mba6x.dtb"
 CONFIG_SYS_PBSIZE=532
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_BOOTZ=y
-- 
2.34.1

[PATCH 1/1] scripts/decodecode: update from Linux v6.10

[Heinrich Schuchardt]

For decoding RISC-V dumps we need to update the script.

Signed-off-by: Heinrich Schuchardt 
---
 scripts/decodecode | 169 +++--
 1 file changed, 148 insertions(+), 21 deletions(-)

diff --git a/scripts/decodecode b/scripts/decodecode
index 9cef558528..6364218b21 100755
--- a/scripts/decodecode
+++ b/scripts/decodecode
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 # SPDX-License-Identifier: GPL-2.0
 # Disassemble the Code: line in Linux oopses
 # usage: decodecode < oops.file
@@ -6,6 +6,9 @@
 # options: set env. variable AFLAGS=options to pass options to "as";
 # e.g., to decode an i386 oops on an x86_64 system, use:
 # AFLAGS=--32 decodecode < 386.oops
+# PC=hex - the PC (program counter) the oops points to
+
+faultlinenum=1
 
 cleanup() {
rm -f $T $T.s $T.o $T.oo $T.aa $T.dis
@@ -60,15 +63,27 @@ case $width in
 4) type=4byte ;;
 esac
 
+if [ -z "$ARCH" ]; then
+case `uname -m` in
+   aarch64*) ARCH=arm64 ;;
+   arm*) ARCH=arm ;;
+   loongarch*) ARCH=loongarch ;;
+esac
+fi
+
+# Params: (tmp_file, pc_sub)
 disas() {
-   ${CROSS_COMPILE}as $AFLAGS -o $1.o $1.s > /dev/null 2>&1
+   t=$1
+   pc_sub=$2
+
+   ${CROSS_COMPILE}as $AFLAGS -o $t.o $t.s > /dev/null 2>&1
 
if [ "$ARCH" = "arm" ]; then
if [ $width -eq 2 ]; then
OBJDUMPFLAGS="-M force-thumb"
fi
 
-   ${CROSS_COMPILE}strip $1.o
+   ${CROSS_COMPILE}strip $t.o
fi
 
if [ "$ARCH" = "arm64" ]; then
@@ -76,11 +91,120 @@ disas() {
type=inst
fi
 
-   ${CROSS_COMPILE}strip $1.o
+   ${CROSS_COMPILE}strip $t.o
+   fi
+
+   if [ "$ARCH" = "riscv" ]; then
+   OBJDUMPFLAGS="-M no-aliases --section=.text -D"
+   ${CROSS_COMPILE}strip $t.o
+   fi
+
+   if [ "$ARCH" = "loongarch" ]; then
+   ${CROSS_COMPILE}strip $t.o
+   fi
+
+   if [ $pc_sub -ne 0 ]; then
+   if [ $PC ]; then
+   adj_vma=$(( $PC - $pc_sub ))
+   OBJDUMPFLAGS="$OBJDUMPFLAGS --adjust-vma=$adj_vma"
+   fi
fi
 
-   ${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $1.o | \
-   grep -v "/tmp\|Disassembly\|\.text\|^$" > $1.dis 2>&1
+   ${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $t.o | \
+   grep -v "/tmp\|Disassembly\|\.text\|^$" > $t.dis 2>&1
+}
+
+# Match the maximum number of opcode bytes from @op_bytes contained within
+# @opline
+#
+# Params:
+# @op_bytes: The string of bytes from the Code: line
+# @opline: The disassembled line coming from objdump
+#
+# Returns:
+# The max number of opcode bytes from the beginning of @op_bytes which match
+# the opcode bytes in the objdump line.
+get_substr_opcode_bytes_num()
+{
+   local op_bytes=$1
+   local opline=$2
+
+   local retval=0
+   substr=""
+
+   for opc in $op_bytes;
+   do
+   substr+="$opc"
+
+   opcode="$substr"
+   if [ "$ARCH" = "riscv" ]; then
+   opcode=$(echo $opcode | tr ' ' '\n' | tac | tr -d '\n')
+   fi
+
+   # return if opcode bytes do not match @opline anymore
+   if ! echo $opline | grep -q "$opcode";
+   then
+   break
+   fi
+
+   # add trailing space
+   substr+=" "
+   retval=$((retval+1))
+   done
+
+   return $retval
+}
+
+# Return the line number in objdump output to where the IP marker in the Code:
+# line points to
+#
+# Params:
+# @all_code: code in bytes without the marker
+# @dis_file: disassembled file
+# @ip_byte: The byte to which the IP points to
+get_faultlinenum()
+{
+   local all_code="$1"
+   local dis_file="$2"
+
+   # num bytes including IP byte
+   local num_bytes_ip=$(( $3 + 1 * $width ))
+
+   # Add the two header lines (we're counting from 1).
+   local retval=3
+
+   # remove marker
+   all_code=$(echo $all_code | sed -e 's/[<>()]//g')
+
+   while read line
+   do
+   get_substr_opcode_bytes_num "$all_code" "$line"
+   ate_opcodes=$?
+
+   if ! (( $ate_opcodes )); then
+   continue
+   fi
+
+   num_bytes_ip=$((num_bytes_ip - ($ate_opcodes * $width) ))
+   if (( $num_bytes_ip <= 0 )); then
+   break
+   fi
+
+   # Delete matched opcode bytes from all_code. For that, compute
+   # how many chars those opcodes are represented by and include
+   # trailing space.
+   #
+   # a byte is 2 chars, ate_opcodes is also the number of trailing
+   # spaces
+   del_chars=$(( ($ate_opcodes * $width * 2) + $ate_opcodes ))
+
+   all_code=$(echo $all_code | sed -e "s!^.\{$del_chars

Re: [PATCH] cmd: add a fetch utility

[Simon Glass]

Hi Caleb,

On Fri, 9 Aug 2024 at 11:00, Caleb Connolly  wrote:
>
> Hi Simon,
>
> On 09/08/2024 03:55, Simon Glass wrote:
> > Hi Caleb,
> >
> > On Thu, 8 Aug 2024 at 10:32, Caleb Connolly  > > wrote:
> >  >
> >  > While U-Boot does a pretty good job at printing information at startup
> >  > about what hardware it's running on, it can be hard to take pretty
> >  > pictures of this to show off on the internet (by far the most
> >  > important aspect of porting a device in 2024!).
> >  >
> >  > Add a small utility "ufetch" for displaying some information about
> > U-Boot and
> >  > the hardware it's running on in a similar fashion to the popular
> > neofetch tool
> >  > for *nix's [1].
> >  >
> >  > While the output is meant to be useful, it should also be pleasing to
> > look at
> >  > and look good in screenshots. The ufetch command brings this to U-Boot,
> >  > featuring a colorful ASCII art version of the U-Boot logo and a fancy
> > layout.
> >  >
> >  > Finally, tireless device porters can properly show off their hard
> > work and get
> >  > the internet points they so deserve!
> >  >
> >  > Not everything is fully supported yet, but this seemed good enough
> > for initial
> >  > inclusion. Only one MMC device is detected, and other than SCSI other
> > storage
> >  > devices aren't supported.
> >  >
> >  > [1]: https://en.wikipedia.org/wiki/Neofetch
> > 
> >  >
> >  > Signed-off-by: Caleb Connolly  > >
> >  > ---
> >  > Ephemeral demo image: https://0x0.st/XVUa.png 
> >  > ---
> >  >  cmd/Kconfig  |   7 ++
> >  >  cmd/Makefile |   1 +
> >  >  cmd/ufetch.c | 201 +++
> >  >  3 files changed, 209 insertions(+)
> >  >  create mode 100644 cmd/ufetch.c
> >
> > Very cute!
> >
> >  >
> >  > diff --git a/cmd/Kconfig b/cmd/Kconfig
> >  > index 978f44eda426..70acb5727b04 100644
> >  > --- a/cmd/Kconfig
> >  > +++ b/cmd/Kconfig
> >  > @@ -175,8 +175,15 @@ config CMD_CPU
> >  >   number of CPUs, type (e.g. manufacturer, architecture,
> > product or
> >  >   internal name) and clock frequency. Other information may be
> >  >   available depending on the CPU driver.
> >  >
> >  > +config CMD_UFETCH
> >  > +   bool "U-Boot fetch"
> >
> > How about default y if SANDBOX so that this gets built for that. You
> > should also add doc/ and test/ for the command (although the test can be
> > very basic).
>
> I was really aiming for cmd/2048.c levels of expectation and usability
> here, not to make this a rugged part of U-Boot's feature set (if someone
> else would like to go the extra mile they're certainly welcome to).
>
> Making it default y for sandbox so we can at least make sure it compiles
> sounds reasonable though.
> >
> >  > +   depends on BLK
> >  > +   help
> >  > + Fetch utility for U-Boot (akin to neofetch). Prints information
> >  > + about U-Boot and the board it is running on in a pleasing
> > format.
> >  > +
> >  >  config CMD_FWU_METADATA
> >  > bool "fwu metadata read"
> >  > depends on FWU_MULTI_BANK_UPDATE
> >  > help
> >  > diff --git a/cmd/Makefile b/cmd/Makefile
> >  > index 87133cc27a8a..ffb04c8f2e0a 100644
> >  > --- a/cmd/Makefile
> >  > +++ b/cmd/Makefile
> >  > @@ -53,8 +53,9 @@ obj-$(CONFIG_CMD_CONSOLE) += console.o
> >  >  obj-$(CONFIG_CMD_CPU) += cpu.o
> >  >  obj-$(CONFIG_CMD_DATE) += date.o
> >  >  obj-$(CONFIG_CMD_DEMO) += demo.o
> >  >  obj-$(CONFIG_CMD_DM) += dm.o
> >  > +obj-$(CONFIG_CMD_UFETCH) += ufetch.o
> >  >  obj-$(CONFIG_CMD_SOUND) += sound.o
> >  >  ifdef CONFIG_POST
> >  >  obj-$(CONFIG_CMD_DIAG) += diag.o
> >  >  endif
> >  > diff --git a/cmd/ufetch.c b/cmd/ufetch.c
> >  > new file mode 100644
> >  > index ..f7374eb2e364
> >  > --- /dev/null
> >  > +++ b/cmd/ufetch.c
> >  > @@ -0,0 +1,201 @@
> >  > +// SPDX-License-Identifier: GPL-2.0
> >  > +
> >  > +/* Small "fetch" utility for U-Boot */
> >
> > Isn't it a command, rather than a utility? I think of a utility as a
> > program I run.
>
> I feel like you could ask 5 different people about this and get 5
> different answers. As a native british english speaker I would view
> "utilities" as a subset of "commands" in this context. This isn't a high
> effort contribution for me so I'm really fine with whatever.

OK I see, fair enough.

> >
> >  > +
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >
> > Please check [1]
>
> Sure, I'll order these alphabetically.
> >
> >  > +
> >  > +DECLARE_GLOBAL_DATA_PTR;
> >  > +
> >  > +#define LINE_WIDTH 40
> >  > +#define BLUE "\033[38;5;4m"
> >  > +#define YELLOW "\033[38;5;11m"
> >  > +#define BOLD "\033[1m"
> >  > +#define RESET "\033[0m"
> >  > +static const char

Re: [PATCH v2 1/3] efi: Allow use of malloc() for the EFI pool

[Simon Glass]

Hi Heinrich,

On Fri, 9 Aug 2024 at 10:38, Heinrich Schuchardt  wrote:
>
> On 01.08.24 19:36, Simon Glass wrote:
> > This API call is intended for allocating small amounts of memory,
> > similar to malloc(). The current implementation rounds up to whole pages
> > which can waste large amounts of memory. It also implements its own
> > malloc()-style header on each block.
> >
> > For certain allocations (those of type EFI_BOOT_SERVICES_DATA) we can
> > use U-Boot's built-in malloc() instead, at least until the app starts.
> > This avoids poluting the memory space with blocks of data which may
> > interfere with boot scripts, etc.
> >
> > Once the app has started, there is no advantage to using malloc(), since
> > it doesn't matter what memory is used: everything is under control of
> > the EFI subsystem. Also, using malloc() after the app starts might
> > result in running of memory, since U-Boot's malloc() space is typically
> > quite small.
> >
> > In fact, malloc() is already used for most EFI-related allocations, so
> > the impact of this change is fairly small.
> >
> > One side effect is that this seems to be showing up some bugs in the
> > EFI code, since the malloc() pool becomes corrupted when running some of
> > the tests.
> >
> > This has likely crept in due to the very large gaps between allocations
> > (around 4KB), which provides a lot of leeway when the allocation size is
> > too small. Work around this by increasing the size for now, until these
> > (presumed) bugs are located.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >   common/dlmalloc.c|   7 +++
> >   include/efi_loader.h |  18 ++
> >   include/malloc.h |   7 +++
> >   lib/efi_loader/efi_bootbin.c |   2 +
> >   lib/efi_loader/efi_memory.c  | 110 ++-
> >   5 files changed, 117 insertions(+), 27 deletions(-)
> >
> > diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> > index 62e8557daa7..0bc77395035 100644
> > --- a/common/dlmalloc.c
> > +++ b/common/dlmalloc.c
> > @@ -613,6 +613,13 @@ void mem_malloc_init(ulong start, ulong size)
> >   #endif
> >   }
> >
> > +bool malloc_check_in_range(void *ptr)
> > +{
> > + ulong val = (ulong)ptr;
> > +
> > + return val >= mem_malloc_start && val < mem_malloc_end;
> > +}
> > +
> >   /* field-extraction macros */
> >
> >   #define first(b) ((b)->fd)
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index f84852e384f..31899bef99e 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -796,6 +796,24 @@ int efi_disk_probe(void *ctx, struct event *event);
> >   int efi_disk_remove(void *ctx, struct event *event);
> >   /* Called by board init to initialize the EFI memory map */
> >   int efi_memory_init(void);
> > +
> > +/**
> > + * enum efi_alloc_flags - controls EFI memory allocation
> > + *
> > + * @EFIAF_USE_MALLOC: Use malloc() pool for pool allocations of type
> > + *   EFI_BOOT_SERVICES_DATA, otherwise use page allocation
> > + */
> > +enum efi_alloc_flags {
> > + EFIAF_USE_MALLOC= BIT(0),
> > +};
> > +
> > +/**
> > + * efi_set_alloc() - Set behaviour of EFI memory allocation
> > + *
> > + * @flags: new value for allocation flags (see enum efi_alloc_flags)
> > + */
> > +void efi_set_alloc(int flags);
> > +
> >   /* Adds new or overrides configuration table entry to the system table */
> >   efi_status_t efi_install_configuration_table(const efi_guid_t *guid, void 
> > *table);
> >   /* Sets up a loaded image */
> > diff --git a/include/malloc.h b/include/malloc.h
> > index 07d3e90a855..a64f117e2f2 100644
> > --- a/include/malloc.h
> > +++ b/include/malloc.h
> > @@ -983,6 +983,13 @@ extern ulong mem_malloc_brk;
> >
> >   void mem_malloc_init(ulong start, ulong size);
> >
> > +/**
> > + * malloc_check_in_range() - Check if a pointer is within the malloc() 
> > region
> > + *
> > + * Return: true if within malloc() region
> > + */
> > +bool malloc_check_in_range(void *ptr);
> > +
> >   #ifdef __cplusplus
> >   };  /* end of extern "C" */
> >   #endif
> > diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> > index a87006b3c0e..5bb0fdcf75d 100644
> > --- a/lib/efi_loader/efi_bootbin.c
> > +++ b/lib/efi_loader/efi_bootbin.c
> > @@ -201,6 +201,8 @@ efi_status_t efi_binary_run(void *image, size_t size, 
> > void *fdt)
> >   {
> >   efi_status_t ret;
> >
> > + efi_set_alloc(0);
> > +
> >   /* Initialize EFI drivers */
> >   ret = efi_init_obj_list();
> >   if (ret != EFI_SUCCESS) {
> > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > index c6f1dd09456..3c3d05eef94 100644
> > --- a/lib/efi_loader/efi_memory.c
> > +++ b/lib/efi_loader/efi_memory.c
> > @@ -24,6 +24,14 @@ DECLARE_GLOBAL_DATA_PTR;
> >   /* Magic number identifying memory allocated from pool */
> >   #define EFI_ALLOC_POOL_MAGIC 0x1fe67ddf6491caa2
> >
> > +/* Flags controlling EFI memory-allocation - see enum efi_alloc_flag

Re: [PATCH v2 3/3] efi: Show the location of the bounce buffer

[Simon Glass]

Hi Heinrich,

On Fri, 9 Aug 2024 at 11:32, Heinrich Schuchardt  wrote:
>
> On 01.08.24 19:36, Simon Glass wrote:
> > The EFI_LOADER_BOUNCE_BUFFER feature was added many years ago. It is not
> > clear whether it is still needed, but 24 boards (lx2160ardb_tfa_stmm,
> > lx2162aqds_tfa_SECURE_BOOT and the like) use it.
> >
> > This feature uses EFI page allocation to create a 64MB buffer 'in space'
> > without any knowledge of where boards intend to load their images. This
> > may result in image corruption or other problems.
> >
> > For example, if the feature is enabled on qemu_arm64 it puts the EFI
> > bounce buffer at 1045MB, with the kernel at 1028MB and the ramdisk at
> > 1088MB. The kernel is probably smaller than 27MB but the buffer does
> > overlap the ramdisk.
> >
> > The solution is probably to use BOUNCE_BUFFER instead, with the EFI
> > version being dropped. For now, show the address of the EFI bounce
> > buffer so people have a better chance to detect the problem.
> >
> > Note: I avoided converting this #ifdef to use IS_ENABLED() since I hope
> > that the feature may be removed.
>
> EFI_BLOCK_IO_PROTOCOL.ReadBlocks() and
> EFI_BLOCK_IO_PROTOCOL.WriteBlocks() are expected to block until all
> bytes are transferred.
>
> The complete file transfer is chunked according to the size of the EFI
> bounce buffer.
>
> Taking care of alignment issues would best handled by the block uclass.
>
> When CONFIG_BOUNCE_BUFFER=y, bounce_buffer_start_extalign() uses
> memalign() which limits the bounce buffer to available malloc() memory
> (typically < 2 MiB).
>
> I cannot see how blk_read() with CONFIG_BOUNCE_BUFFER=y will work if
> blkcnt * desc->blksz is greater than the available malloc memory.

Yes, it uses malloc(). The maximum read length on MMC, for example,
seems to default to 32MB, although it is only 128KB on a few
platforms.

I am thinking we should be allocating space in the bloblist to hold
all these sorts of things...it can be as large as needed and we can
allocate space for it during relocation.

>
> Shouldn't the block uclass support chunking?

It only supports readling whole blocks, if that is what you mean. Are
you suggesting changing the blk API, or something else?

Regards,
Simon



>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Drop patch 'Show more information in efi index'
> > - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
> > - Add the word 'warning', use log_warning() and show the end address
> > - Reorder patches a little
> >
> >   lib/efi_loader/efi_bootbin.c | 9 +
> >   1 file changed, 9 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> > index 5bb0fdcf75d..9779dc09b5e 100644
> > --- a/lib/efi_loader/efi_bootbin.c
> > +++ b/lib/efi_loader/efi_bootbin.c
> > @@ -211,6 +211,15 @@ efi_status_t efi_binary_run(void *image, size_t size, 
> > void *fdt)
> >   return -1;
> >   }
> >
> > +#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
> > + /*
> > +  * Add a warning about this buffer, since it may conflict with other
> > +  * things
> > +  */
> > + log_warning("Warning: EFI bounce buffer %p-%p\n", efi_bounce_buffer,
> > + efi_bounce_buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
> > +#endif
> > +
> >   ret = efi_install_fdt(fdt);
> >   if (ret != EFI_SUCCESS)
> >   return ret;
>

Re: [PATCH 00/20] i2c: Chip away at some old code

[Simon Glass]

-cc most

Hi,

On Thu, 18 Jul 2024 at 11:36, Simon Glass  wrote:
>
> This series aims to remove some of the older contents of i2c.h so that
> we can move towards having just the dm API.
>
> It removes four boards which are getting in the way.
>
>
> Simon Glass (20):
>   arm: Remove pg_wcom boards
>   i2c: Remove board_i2c_init()
>   i2c: Remove IC2_xxx enum
>   i2c: Remove CFG_I2C_MULTI_BUS
>   mips: malta: Drop CMD_DATE
>   armv8: ls2085a: Drop CMD_DATE
>   mx28 / mx51: Drop CMD_DATE
>   MPC837XERDB: ethernut5: work_92105: Drop CMD_DATE
>   rtc: Drop CFG_SYS_RTC_BUS_NUM
>   date: Drop the legacy I2C code
>   keymile: Remove use of legacy I2C
>   i2c: mxc: pg_wcom: Drop legacy I2c
>   i2c: Drop reference to SYS_I2C_INIT_BOARD
>   octeon: Drop OCTEON_I2C_FDT dead code
>   i2c: Remove I2C_SET_BUS()
>   i2c: Remove I2C_GET_BUS()
>   i2c: Drop CFG_SYS_MAX_I2C_BUS
>   i2c: Drop i2c_get_bus_num_fdt() and i2c_reset_port_fdt()
>   i2c: Remove CFG_SYS_I2C_MAX_HOPS
>   i2c: Remove CFG_SYS_I2C_DIRECT_BUS
>
>  README|  27 +--
>  arch/arm/dts/ls1021a-pg-wcom-expu1.dts| 141 ---
>  arch/arm/dts/ls1021a-pg-wcom-seli8.dts| 124 --
>  arch/mips/mach-octeon/octeon_fdt.c|  22 --
>  board/keymile/Kconfig |   4 -
>  board/keymile/common/common.c |  69 --
>  board/keymile/pg-wcom-ls102xa/Kconfig |  39 
>  board/keymile/pg-wcom-ls102xa/MAINTAINERS |  16 --
>  board/keymile/pg-wcom-ls102xa/Makefile|  11 -
>  board/keymile/pg-wcom-ls102xa/ddr.c   |  91 
>  .../keymile/pg-wcom-ls102xa/pg-wcom-expu1.env |   3 -
>  .../keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 218 --
>  .../keymile/pg-wcom-ls102xa/pg-wcom-seli8.env |   3 -
>  cmd/date.c|  32 ---
>  cmd/i2c.c |  23 --
>  configs/MPC837XERDB_defconfig |   1 -
>  configs/ethernut5_defconfig   |   1 -
>  configs/ls2080aqds_nand_defconfig |   1 -
>  configs/ls2080aqds_qspi_defconfig |   1 -
>  configs/ls2080ardb_nand_defconfig |   1 -
>  configs/malta64_defconfig |   1 -
>  configs/malta64el_defconfig   |   1 -
>  configs/malta_defconfig   |   1 -
>  configs/maltael_defconfig |   1 -
>  configs/mx28evk_defconfig |   1 -
>  configs/mx51evk_defconfig |   1 -
>  configs/pg_wcom_expu1_defconfig   | 109 -
>  configs/pg_wcom_expu1_update_defconfig| 107 -
>  configs/pg_wcom_seli8_defconfig   | 109 -
>  configs/pg_wcom_seli8_update_defconfig| 107 -
>  configs/work_92105_defconfig  |   1 -
>  doc/I2C_Edge_Conditions   |  10 +-
>  drivers/ddr/fsl/main.c|   3 +-
>  drivers/i2c/i2c_core.c| 141 ---
>  drivers/i2c/soft_i2c.c|  11 -
>  drivers/power/power_i2c.c |   5 -
>  drivers/usb/host/ohci-lpc32xx.c   |   4 -
>  include/configs/ethernut5.h   |   3 -
>  include/configs/km/pg-wcom-ls102xa.h  | 167 --
>  include/configs/ls1028aqds.h  |   1 -
>  include/configs/ls1028ardb.h  |   2 -
>  include/configs/ls1046afrwy.h |   1 -
>  include/configs/lx2160aqds.h  |   3 -
>  include/configs/lx2160ardb.h  |   3 -
>  include/configs/lx2162aqds.h  |   3 -
>  include/configs/m53menlo.h|   2 -
>  include/configs/omap3_beagle.h|   3 -
>  include/configs/pg-wcom-expu1.h   |  49 
>  include/configs/pg-wcom-seli8.h   |  40 
>  include/configs/sniper.h  |  14 --
>  include/configs/tqma6.h   |   3 -
>  include/configs/tqma6_wru4.h  |   1 -
>  include/i2c.h | 107 -
>  53 files changed, 6 insertions(+), 1837 deletions(-)
>  delete mode 100644 arch/arm/dts/ls1021a-pg-wcom-expu1.dts
>  delete mode 100644 arch/arm/dts/ls1021a-pg-wcom-seli8.dts
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/Kconfig
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/MAINTAINERS
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/Makefile
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/ddr.c
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-expu1.env
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
>  delete mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-seli8.env
>  delete mode 100644 configs/pg_wcom_expu1_defconfig
>  delete mode 100644 configs/pg_wcom_expu1_update_defconfig
>  delete mode 100644 configs/pg_wcom_seli8_defconfig
>  delete mode 100644 configs/pg_wcom

Pull request for tpm-master-09082024

[Ilias Apalodimas]

Hi Tom,

The following changes since commit 6f4c31c2b658358628b5b0fa801f55c7477c7585:

  Prepare v2024.10-rc2 (2024-08-05 18:13:42 -0600)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-09082024

for you to fetch changes up to c686b38db8f84e5537b8371ac59a5b364662eda4:

  tpm: call tpm_tis_wait_init() after tpm_tis_init() (2024-08-06 14:01:14 +0300)

The pipeline in 
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/21949
showed no problems


Back when the TPM subsystem was refactored tpm_tis_wait_init() ended up
being called after tpm_tis_init() which initializes values the former needs.

Since we added more TPM chipsets since then sitting on an i2c bus, this patch
folds in tpm_tis_wait_init into tpm_tis_init and makes sure it's called in the
right order regardless of the bus the TPM sits on.


Lukas Funke (1):
  tpm: call tpm_tis_wait_init() after tpm_tis_init()

 drivers/tpm/tpm2_tis_core.c | 28 
 drivers/tpm/tpm2_tis_spi.c  | 30 --
 2 files changed, 28 insertions(+), 30 deletions(-)

Re: [PATCH 00/20] i2c: Chip away at some old code

[Tom Rini]

On Fri, Aug 09, 2024 at 12:37:52PM -0600, Simon Glass wrote:
> -cc most
> 
> Hi,
> 
> On Thu, 18 Jul 2024 at 11:36, Simon Glass  wrote:
> >
> > This series aims to remove some of the older contents of i2c.h so that
> > we can move towards having just the dm API.
> >
> > It removes four boards which are getting in the way.
> >
> >
> > Simon Glass (20):
> >   arm: Remove pg_wcom boards
> >   i2c: Remove board_i2c_init()
> >   i2c: Remove IC2_xxx enum
> >   i2c: Remove CFG_I2C_MULTI_BUS
> >   mips: malta: Drop CMD_DATE
> >   armv8: ls2085a: Drop CMD_DATE
> >   mx28 / mx51: Drop CMD_DATE
> >   MPC837XERDB: ethernut5: work_92105: Drop CMD_DATE
> >   rtc: Drop CFG_SYS_RTC_BUS_NUM
> >   date: Drop the legacy I2C code
> >   keymile: Remove use of legacy I2C
> >   i2c: mxc: pg_wcom: Drop legacy I2c
> >   i2c: Drop reference to SYS_I2C_INIT_BOARD
> >   octeon: Drop OCTEON_I2C_FDT dead code
> >   i2c: Remove I2C_SET_BUS()
> >   i2c: Remove I2C_GET_BUS()
> >   i2c: Drop CFG_SYS_MAX_I2C_BUS
> >   i2c: Drop i2c_get_bus_num_fdt() and i2c_reset_port_fdt()
> >   i2c: Remove CFG_SYS_I2C_MAX_HOPS
> >   i2c: Remove CFG_SYS_I2C_DIRECT_BUS
> >
> >  README|  27 +--
> >  arch/arm/dts/ls1021a-pg-wcom-expu1.dts| 141 ---
> >  arch/arm/dts/ls1021a-pg-wcom-seli8.dts| 124 --
> >  arch/mips/mach-octeon/octeon_fdt.c|  22 --
> >  board/keymile/Kconfig |   4 -
> >  board/keymile/common/common.c |  69 --
> >  board/keymile/pg-wcom-ls102xa/Kconfig |  39 
> >  board/keymile/pg-wcom-ls102xa/MAINTAINERS |  16 --
> >  board/keymile/pg-wcom-ls102xa/Makefile|  11 -
> >  board/keymile/pg-wcom-ls102xa/ddr.c   |  91 
> >  .../keymile/pg-wcom-ls102xa/pg-wcom-expu1.env |   3 -
> >  .../keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 218 --
> >  .../keymile/pg-wcom-ls102xa/pg-wcom-seli8.env |   3 -
> >  cmd/date.c|  32 ---
> >  cmd/i2c.c |  23 --
> >  configs/MPC837XERDB_defconfig |   1 -
> >  configs/ethernut5_defconfig   |   1 -
> >  configs/ls2080aqds_nand_defconfig |   1 -
> >  configs/ls2080aqds_qspi_defconfig |   1 -
> >  configs/ls2080ardb_nand_defconfig |   1 -
> >  configs/malta64_defconfig |   1 -
> >  configs/malta64el_defconfig   |   1 -
> >  configs/malta_defconfig   |   1 -
> >  configs/maltael_defconfig |   1 -
> >  configs/mx28evk_defconfig |   1 -
> >  configs/mx51evk_defconfig |   1 -
> >  configs/pg_wcom_expu1_defconfig   | 109 -
> >  configs/pg_wcom_expu1_update_defconfig| 107 -
> >  configs/pg_wcom_seli8_defconfig   | 109 -
> >  configs/pg_wcom_seli8_update_defconfig| 107 -
> >  configs/work_92105_defconfig  |   1 -
> >  doc/I2C_Edge_Conditions   |  10 +-
> >  drivers/ddr/fsl/main.c|   3 +-
> >  drivers/i2c/i2c_core.c| 141 ---
> >  drivers/i2c/soft_i2c.c|  11 -
> >  drivers/power/power_i2c.c |   5 -
> >  drivers/usb/host/ohci-lpc32xx.c   |   4 -
> >  include/configs/ethernut5.h   |   3 -
> >  include/configs/km/pg-wcom-ls102xa.h  | 167 --
> >  include/configs/ls1028aqds.h  |   1 -
> >  include/configs/ls1028ardb.h  |   2 -
> >  include/configs/ls1046afrwy.h |   1 -
> >  include/configs/lx2160aqds.h  |   3 -
> >  include/configs/lx2160ardb.h  |   3 -
> >  include/configs/lx2162aqds.h  |   3 -
> >  include/configs/m53menlo.h|   2 -
> >  include/configs/omap3_beagle.h|   3 -
> >  include/configs/pg-wcom-expu1.h   |  49 
> >  include/configs/pg-wcom-seli8.h   |  40 
> >  include/configs/sniper.h  |  14 --
> >  include/configs/tqma6.h   |   3 -
> >  include/configs/tqma6_wru4.h  |   1 -
> >  include/i2c.h | 107 -
> >  53 files changed, 6 insertions(+), 1837 deletions(-)
> >  delete mode 100644 arch/arm/dts/ls1021a-pg-wcom-expu1.dts
> >  delete mode 100644 arch/arm/dts/ls1021a-pg-wcom-seli8.dts
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/Kconfig
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/MAINTAINERS
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/Makefile
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/ddr.c
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-expu1.env
> >  delete mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
> >  delete mode 100644

Re: [PATCH v2 3/3] efi: Show the location of the bounce buffer

[Heinrich Schuchardt]

Am 9. August 2024 20:36:35 MESZ schrieb Simon Glass :
>Hi Heinrich,
>
>On Fri, 9 Aug 2024 at 11:32, Heinrich Schuchardt  wrote:
>>
>> On 01.08.24 19:36, Simon Glass wrote:
>> > The EFI_LOADER_BOUNCE_BUFFER feature was added many years ago. It is not
>> > clear whether it is still needed, but 24 boards (lx2160ardb_tfa_stmm,
>> > lx2162aqds_tfa_SECURE_BOOT and the like) use it.
>> >
>> > This feature uses EFI page allocation to create a 64MB buffer 'in space'
>> > without any knowledge of where boards intend to load their images. This
>> > may result in image corruption or other problems.
>> >
>> > For example, if the feature is enabled on qemu_arm64 it puts the EFI
>> > bounce buffer at 1045MB, with the kernel at 1028MB and the ramdisk at
>> > 1088MB. The kernel is probably smaller than 27MB but the buffer does
>> > overlap the ramdisk.
>> >
>> > The solution is probably to use BOUNCE_BUFFER instead, with the EFI
>> > version being dropped. For now, show the address of the EFI bounce
>> > buffer so people have a better chance to detect the problem.
>> >
>> > Note: I avoided converting this #ifdef to use IS_ENABLED() since I hope
>> > that the feature may be removed.
>>
>> EFI_BLOCK_IO_PROTOCOL.ReadBlocks() and
>> EFI_BLOCK_IO_PROTOCOL.WriteBlocks() are expected to block until all
>> bytes are transferred.
>>
>> The complete file transfer is chunked according to the size of the EFI
>> bounce buffer.
>>
>> Taking care of alignment issues would best handled by the block uclass.
>>
>> When CONFIG_BOUNCE_BUFFER=y, bounce_buffer_start_extalign() uses
>> memalign() which limits the bounce buffer to available malloc() memory
>> (typically < 2 MiB).
>>
>> I cannot see how blk_read() with CONFIG_BOUNCE_BUFFER=y will work if
>> blkcnt * desc->blksz is greater than the available malloc memory.
>
>Yes, it uses malloc(). The maximum read length on MMC, for example,
>seems to default to 32MB, although it is only 128KB on a few
>platforms.
>
>I am thinking we should be allocating space in the bloblist to hold
>all these sorts of things...it can be as large as needed and we can
>allocate space for it during relocation.
>
>>
>> Shouldn't the block uclass support chunking?
>
>It only supports readling whole blocks, if that is what you mean. Are
>you suggesting changing the blk API, or something else?

It supports reading multiple blocks. If not all blocks fit into the memory that 
can be assigned via memalgn, the block layer coud separate the blocks into 
chunks. This would replace the EFI bounce buffer.




>
>Regards,
>Simon
>
>
>
>>
>> Best regards
>>
>> Heinrich
>>
>> >
>> > Signed-off-by: Simon Glass 
>> > ---
>> >
>> > Changes in v2:
>> > - Drop patch 'Show more information in efi index'
>> > - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
>> > - Add the word 'warning', use log_warning() and show the end address
>> > - Reorder patches a little
>> >
>> >   lib/efi_loader/efi_bootbin.c | 9 +
>> >   1 file changed, 9 insertions(+)
>> >
>> > diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
>> > index 5bb0fdcf75d..9779dc09b5e 100644
>> > --- a/lib/efi_loader/efi_bootbin.c
>> > +++ b/lib/efi_loader/efi_bootbin.c
>> > @@ -211,6 +211,15 @@ efi_status_t efi_binary_run(void *image, size_t size, 
>> > void *fdt)
>> >   return -1;
>> >   }
>> >
>> > +#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
>> > + /*
>> > +  * Add a warning about this buffer, since it may conflict with other
>> > +  * things
>> > +  */
>> > + log_warning("Warning: EFI bounce buffer %p-%p\n", efi_bounce_buffer,
>> > + efi_bounce_buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
>> > +#endif
>> > +
>> >   ret = efi_install_fdt(fdt);
>> >   if (ret != EFI_SUCCESS)
>> >   return ret;
>>

Re: [PATCH v2 9/9] doc: introduce led.rst documentation

[Christian Marangi]

On Thu, Aug 08, 2024 at 08:34:32AM +0200, Alexander Dahl wrote:
> Hello Christian,
> 
> Am Wed, Aug 07, 2024 at 09:54:12PM +0200 schrieb Christian Marangi:
> > Introduce simple led.rst documentation to document all the additional
> > Kconfig and the current limitation of LED_BLINK and GPIO software blink.
> 
> This is a good idea.  An overview of all the LED possibilities in the
> Documentation is much appreciated.  Remarks below.
> 
> > 
> > Signed-off-by: Christian Marangi 
> > ---
> >  doc/api/index.rst |  1 +
> >  doc/api/led.rst   | 10 ++
> >  include/led.h | 38 ++
> >  3 files changed, 49 insertions(+)
> >  create mode 100644 doc/api/led.rst
> > 
> > diff --git a/doc/api/index.rst b/doc/api/index.rst
> > index ec0b8adb2cf..9f7f23f868f 100644
> > --- a/doc/api/index.rst
> > +++ b/doc/api/index.rst
> > @@ -14,6 +14,7 @@ U-Boot API documentation
> > event
> > getopt
> > interrupt
> > +   led
> > linker_lists
> > lmb
> > logging
> > diff --git a/doc/api/led.rst b/doc/api/led.rst
> > new file mode 100644
> > index 000..e52e350d1bb
> > --- /dev/null
> > +++ b/doc/api/led.rst
> > @@ -0,0 +1,10 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +
> > +LED
> > +===
> > +
> > +.. kernel-doc:: include/led.h
> > +   :doc: Overview
> > +
> > +.. kernel-doc:: include/led.h
> > +   :internal:
> > \ No newline at end of file
> > diff --git a/include/led.h b/include/led.h
> > index 61ece70a975..77b18ddffbf 100644
> > --- a/include/led.h
> > +++ b/include/led.h
> > @@ -10,6 +10,44 @@
> >  #include 
> >  #include 
> >  
> > +/**
> > + * DOC: Overview
> > + *
> > + * Generic LED API provided when a supported compatible is defined in 
> > DeviceTree.
> > + *
> > + * To enable support for LEDs, enable the `CONFIG_LED` Kconfig option.
> > + *
> > + * The most common implementation is for GPIO-connected LEDs. If using 
> > GPIO-connected LEDs,
> > + * enable the `LED_GPIO` Kconfig option.
> > + *
> > + * `LED_BLINK` support requires LED driver support and is therefore 
> > optional. If LED blink
> > + * functionality is needed, enable the `LED_BLINK` Kconfig option. If LED 
> > driver doesn't
> > + * support HW Blink, SW Blink can be used with the Cyclic framework by 
> > enabling the
> > + * CONFIG_LED_SW_BLINK.
> > + *
> > + * Boot and Activity LEDs are also supported. These LEDs can signal 
> > various system operations
> > + * during runtime, such as boot initialization, file transfers, and flash 
> > write/erase operations.
> > + *
> > + * To enable a Boot LED, enable `CONFIG_LED_BOOT_ENABLE` and define 
> > `CONFIG_LED_BOOT_LABEL`. This
> > + * will enable the specified LED to blink and turn ON when the bootloader 
> > initializes correctly.
> 
> This is somehow redundant to defining "u-boot,boot-led" in
> *-u-boot.dtsi snippets, isn't it?  This is documented in
> doc/device-tree-bindings/config.txt and used by roughly a dozen dtsi
> files and five times in board code.  It also stores a LED label, which
> board code can make use of then, but I think it's not further
> integrated in any driver or class code.  Are you aware of that mechanism
> and hwo does it fit into your rework of the boot led?
>

No I wasn't aware of those property. I will check how that can be
expanded and implemented here as it seems a better way than raw configs.

> 
> > + *
> > + * To enable an Activity LED, enable `CONFIG_LED_ACTIVITY_ENABLE` and 
> > define
> > + * `CONFIG_LED_ACTIVITY_LABEL`.
> > + * This will enable the specified LED to blink and turn ON during file 
> > transfers or flash
> > + * write/erase operations.
> > + *
> > + * Both Boot and Activity LEDs provide a simple API to turn the LED ON or 
> > OFF:
> > + * `led_boot_on()`, `led_boot_off()`, `led_activity_on()`, and 
> > `led_activity_off()`.
> > + *
> > + * Both configurations can optionally define a `_PERIOD` option if 
> > `CONFIG_LED_BLINK` or
> > + * `CONFIG_LED_SW_BLINK` is enabled for LED blink operations, which is 
> > usually used by
> > + * the Activity LED.
> > + *
> > + * When `CONFIG_LED_BLINK` or `CONFIG_LED_SW_BLINK` is enabled, additional 
> > APIs are exposed:
> > + * `led_boot_blink()` and `led_activity_blink()`. Note that if 
> > `CONFIG_LED_BLINK` is disabled,
> > + * these APIs will behave like the `led_boot_on()` and `led_activity_on()` 
> > APIs, respectively.
> > + */
> > +
> >  struct udevice;
> >  
> >  enum led_state_t {
> > -- 
> > 2.45.2
> > 

-- 
Ansuel

[PATCH v2] env: remove vars that are not in default env

[Ravi Minnikanti]

current env_set_default_vars() doesn't delete
var that are not in the imported env. hashtable
removes vars that are not in the imported
env but present in the current env only if H_NOCLEAR
flag is not set.

This change is to avoid passing H_NOCLEAR flag if
specific vars are passed to env_set_default_vars()

Without this change:
Marvell>> env default boot_mode
Marvell>>

With the change:
Marvell>> env default boot_mode
WARNING: 'boot_mode' not in imported env, deleting it!

Signed-off-by: rminnikanti 
---
Changes in v2:
- Added env ut to test the scenario
- Updated doc usage/cmd/env.rst

=> ut env
Running 5 environment tests
Test: env_test_attrs_lookup: attr.c
Test: env_test_attrs_lookup_regex: attr.c
Test: env_test_env_cmd: cmd_ut_env.c
Test: env_test_htab_deletes: hashtable.c
Test: env_test_htab_fill: hashtable.c
Failures: 0

 doc/usage/cmd/env.rst |  4 +++-
 env/common.c  | 10 +-
 test/env/cmd_ut_env.c | 36 
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/doc/usage/cmd/env.rst b/doc/usage/cmd/env.rst
index 9629f97ffc..9104c88525 100644
--- a/doc/usage/cmd/env.rst
+++ b/doc/usage/cmd/env.rst
@@ -79,7 +79,8 @@ The *env default* command resets the selected variables in 
the U-Boot
 environment to their default values.
 
 var
-list of variable name.
+list of variable name. If variable is not part of default
+environment, it is deleted with a warning message on console.
 \-a
 all U-Boot environment.
 \-f
@@ -309,6 +310,7 @@ Delete environment variable in memory::
 Reset environment variable to default value, in memory::
 
 => env default bootcmd
+=> env default ipaddr serverip
 => env default -a
 
 Save current environment in persistent storage::
diff --git a/env/common.c b/env/common.c
index 8d47d72605..2f783e3a69 100644
--- a/env/common.c
+++ b/env/common.c
@@ -401,7 +401,15 @@ int env_set_default_vars(int nvars, char * const vars[], 
int flags)
 * Special use-case: import from default environment
 * (and use \0 as a separator)
 */
-   flags |= H_NOCLEAR | H_DEFAULT;
+
+   /* 
+* When vars are passed remove variables that are not in
+* the default environment.
+*/
+   if (!nvars)
+   flags |= H_NOCLEAR;
+
+   flags |= H_DEFAULT;
return himport_r(&env_htab, default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
diff --git a/test/env/cmd_ut_env.c b/test/env/cmd_ut_env.c
index 13e0998341..99961311aa 100644
--- a/test/env/cmd_ut_env.c
+++ b/test/env/cmd_ut_env.c
@@ -9,6 +9,42 @@
 #include 
 #include 
 
+static int env_test_env_cmd(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+   ut_assertok(run_command("setenv non_default_var1 1", 0));
+   ut_assert_console_end();
+
+   console_record_reset_enable();
+   ut_assertok(run_command("setenv non_default_var2 1", 0));
+   ut_assert_console_end();
+
+   console_record_reset_enable();
+   ut_assertok(run_command("env print non_default_var1", 0));
+   ut_assert_nextline("non_default_var1=1");
+   ut_assert_console_end();
+
+   console_record_reset_enable();
+   ut_assertok(run_command("env default non_default_var1 
non_default_var2", 0));
+   ut_assert_nextline("WARNING: 'non_default_var1' not in imported env, 
deleting it!");
+   ut_assert_nextline("WARNING: 'non_default_var2' not in imported env, 
deleting it!");
+   ut_assert_console_end();
+
+   console_record_reset_enable();
+   ut_asserteq(1, run_command("env exists non_default_var1", 0));
+   ut_assert_nextline_empty();
+   ut_assert_console_end();
+
+   console_record_reset_enable();
+   ut_asserteq(1, run_command("env exists non_default_var2", 0));
+   ut_assert_nextline_empty();
+   ut_assert_console_end();
+
+   return 0;
+}
+
+ENV_TEST(env_test_env_cmd, 0);
+
 int do_ut_env(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
struct unit_test *tests = UNIT_TEST_SUITE_START(env_test);
-- 
2.25.1

Thanks,
Ravi

On 8/9/24 08:58, Simon Glass wrote:
> Hi Ravi, On Fri, 9 Aug 2024 at 09: 38, Ravi Minnikanti   com> wrote: > > > current env_set_default_vars() doesn't delete > var that 
> are 
> not in the imported env. hashtable > removes vars that are not in
> 
> 
> Hi Ravi,
> 
> On Fri, 9 Aug 2024 at 09:38, Ravi Minnikanti  wrote:
>>
>>
>> current env_set_default_vars() doesn't delete
>> var that are not in the imported env. hashtable
>> removes vars that are not in the imported
>> env but present in the current env only if H_NOCLEAR
>> flag is not set.
>>
>> This change is to avoid passing H_NOCLEAR flag if
>> specific vars are passed to env_set_default_vars()
>>
>> Test:
>>
>> Without this change:
>> Marvell>> env default boot_mode
>> Marvell>>
>>
>> With the change:
>> Marvell>> env

Re: Please pull v2 u-boot-i2c

[Tom Rini]

On Fri, Aug 09, 2024 at 04:09:09PM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c master, sorted out the DM_I2C patches from 
> Anatolij,
> to seperate pull request for next.
> 
> The following changes since commit eb8e25c000d185ece0136b13cca73084eb980253:
> 
>   Merge tag 'u-boot-nand-20240808' of
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash (2024-08-08
> 16:15:06 -0600)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 
> tags/i2cfixes-v2-for-v2024-10-rc3
> 
> for you to fetch changes up to ec07bcc8eafb8d201d15facc969fe96600660095:
> 
>   i2c: imx_lpi2c: Support read transfers longer than 256 bytes (2024-08-09 
> 14:46:49 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-i2c next

[Tom Rini]

On Fri, Aug 09, 2024 at 04:09:19PM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c next
> 
> The following changes since commit 2078abaf00b63fc4f70f8a599b61a476e22352f3:
> 
>   Merge patch series "alist: Implement a pointer list / array of structs" 
> (2024-08-07 08:51:25 -0600)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 
> tags/i2cupdates-for-v2024-10-next
> 
> for you to fetch changes up to b08ee931ba55cf6196faf7f9d0613e325971f31f:
> 
>   board: vining_2000: convert to DM_I2C (2024-08-09 06:27:27 +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v8 00/23] Introduce the lwIP network stack

[Tom Rini]

On Fri, Aug 09, 2024 at 03:19:02PM +0200, Jerome Forissier wrote:
> 
> 
> On 8/8/24 19:24, Tom Rini wrote:
> > On Thu, Aug 08, 2024 at 06:41:02PM +0200, Jerome Forissier wrote:
> >>
> >>
> >> On 8/7/24 22:44, Tom Rini wrote:
> >>> On Wed, Aug 07, 2024 at 07:11:44PM +0200, Jerome Forissier wrote:
> >>>
>  This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
>  library for the network stack" [1]. The goal is to introduce the lwIP 
>  TCP/IP
>  stack [2] [3] as an alternative to the current implementation in net/,
>  selectable with Kconfig, and ultimately keep only lwIP if possible. Some
>  reasons for doing so are:
>  - Make the support of HTTPS in the wget command easier. Javier T. and
>  Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do
>  so. With that it becomes possible to fetch and launch a distro installer
>  such as Debian etc. using a secure, authenticated connection directly
>  from the U-Boot shell. Several use cases:
>    * Authentication: prevent MITM attack (third party replacing the
>  binary with a different one)
>    * Confidentiality: prevent third parties from grabbing a copy of the
>  image as it is being downloaded
>    * Allow connection to servers that do not support plain HTTP anymore
>  (this is becoming more and more common on the Internet these days)
>  - Possibly benefit from additional features implemented in lwIP
>  - Less code to maintain in U-Boot
> 
>  Prior to applying this series, the lwIP stack needs to be added as a
>  Git subtree with the following command:
> 
>   $  git subtree add --squash --prefix lib/lwip/lwip 
>  https://git.savannah.gnu.org/git/lwip.git STABLE-2_2_0_RELEASE
> >>>
> >>> For v9, I think it would be good to do a CI run with NET_LWIP default
> >>> and seeing what fails from that too. There's a few problems still
> >>> leading to a lot of failures, in that case. Thanks.
> >>
> >> I pushed my branch to GitHub [1] and there's a failure in the
> >> tools_only_macOS job [2]. Any idea what is going on? I tried twice and
> >> it failed twice :-/
> >> Om my Linux machine, "make tools-only_config tools-only" works
> >> fine.
> >>
> >> [1] https://github.com/u-boot/u-boot/pull/635
> >> [2] 
> >> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results
> > 
> > Alright so from [2] going to the job and then downloading the raw log (it's
> > huge, firefox gets mad for me), scrolling down until it's not the git clone 
> > we
> > see:
> > 2024-08-08T14:36:30.0865130Z   HOSTCC  scripts/basic/fixdep
> > 2024-08-08T14:36:30.8641660Z   HOSTCC  scripts/kconfig/conf.o
> > 2024-08-08T14:36:30.9645180Z   LEX scripts/kconfig/zconf.lex.c
> > 2024-08-08T14:36:31.0545650Z   YACCscripts/kconfig/zconf.tab.c
> > 2024-08-08T14:36:33.2374910Z   HOSTCC  scripts/kconfig/zconf.tab.o
> > 2024-08-08T14:36:34.9997050Z   HOSTLD  scripts/kconfig/conf
> > 2024-08-08T14:36:36.5552790Z generated_defconfig:7:warning: unexpected 
> > data:  # CONFIG_SANDBOX_
> > SDL is not set
> > 2024-08-08T14:36:36.5666380Z generated_defconfig:12:warning: unexpected 
> > data:  # CONFIG_BOOTSTD
> > _FULL is not set
> > 2024-08-08T14:36:36.5724560Z generated_defconfig:13:warning: unexpected 
> > data:  # CONFIG_BOOTMET
> > H_CROS is not set
> > 2024-08-08T14:36:36.5742720Z generated_defconfig:14:warning: unexpected 
> > data:  # CONFIG_BOOTMET
> > H_VBE is not set
> > 2024-08-08T14:36:36.5752700Z generated_defconfig:17:warning: unexpected 
> > data:  # CONFIG_CMD_BOO
> > TD is not set
> > 2024-08-08T14:36:36.5772400Z generated_defconfig:18:warning: unexpected 
> > data:  # CONFIG_CMD_BOO
> > TM is not set
> > 2024-08-08T14:36:36.5788060Z generated_defconfig:19:warning: unexpected 
> > data:  # CONFIG_CMD_BOO
> > TI is not set
> > 2024-08-08T14:36:36.5792360Z generated_defconfig:20:warning: unexpected 
> > data:  # CONFIG_CMD_ELF
> >  is not set
> > 2024-08-08T14:36:36.5828400Z generated_defconfig:21:warning: unexpected 
> > data:  # CONFIG_CMD_EXTENSION is not set
> > 2024-08-08T14:36:36.5840470Z generated_defconfig:22:warning: unexpected 
> > data:  # CONFIG_CMD_DAT
> > E is not set
> > 2024-08-08T14:36:36.5938540Z generated_defconfig:26:warning: unexpected 
> > data:  # CONFIG_ACPIGEN
> >  is not set
> > 2024-08-08T14:36:36.5974000Z generated_defconfig:35:warning: unexpected 
> > data:  # CONFIG_VIRTIO_MMIO is not set
> > 2024-08-08T14:36:36.5985430Z generated_defconfig:36:warning: unexpected 
> > data:  # CONFIG_VIRTIO_PCI is not set
> > 2024-08-08T14:36:36.6045140Z generated_defconfig:37:warning: unexpected 
> > data:  # CONFIG_VIRTIO_SANDBOX is not set
> > 2024-08-08T14:36:36.6053060Z generated_defconfig:38:warning: unexpected 
> > data:  # CONFIG_GENERATE_ACPI_TABLE is not set
> > 2024-08-08T14:36:36.6068760Z generated_defconfig:39:warning: unexpected 
> > data:  # CONFIG_EFI_LOADER is not set
> > 2024-08-08T14:36:36.6088140Z #
> > 2024-08-

Re: [PATCH v2 2/2] i2c: samsung: Support platforms other than EXYNOS4 and EXYNOS5

[Henrik Grimler]

Hi David,

Thinking about this a bit more...

On Fri, Aug 02, 2024 at 09:19:16PM +0200, David Virag wrote:
> Newer Samsung SoCs (including newer Exynos, ExynosAuto, Google Tensor)
> still use these IPs, or slightly newer versions of it.
> 
> Make these drivers available on these platforms by guarding
> EXYNOS4/EXYNOS5 specific code behind their configs, and using CCF for
> clocks on other platforms.
> 
> Tested S3C I2C driver on Exynos7885.
> This along with extended clock driver should enable S3C I2C on
> Exynos850.
> 
> Signed-off-by: David Virag 
> ---
>  drivers/i2c/Kconfig |  2 +-
>  drivers/i2c/exynos_hs_i2c.c | 25 +++--
>  drivers/i2c/s3c24x0_i2c.c   | 30 +++---
>  drivers/i2c/s3c24x0_i2c.h   |  2 ++
>  4 files changed, 53 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index cba7f84894..52067fa7c1 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -650,7 +650,7 @@ config SYS_I2C_GENI
>  
>  config SYS_I2C_S3C24X0
>   bool "Samsung I2C driver"
> - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && DM_I2C
> + depends on DM_I2C
>   help
> Support for Samsung I2C controller as Samsung SoCs.
>  
> diff --git a/drivers/i2c/exynos_hs_i2c.c b/drivers/i2c/exynos_hs_i2c.c
> index 189ce6d509..fa0d1c8f64 100644
> --- a/drivers/i2c/exynos_hs_i2c.c
> +++ b/drivers/i2c/exynos_hs_i2c.c
> @@ -9,11 +9,15 @@
>  #include 
>  #include 
>  #include 
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARCH_EXYNOS5)
>  #include 
>  #include 
>  #include 
> +#endif

We want to try to move the Exynos 4 and 5 devices to CCF and
OF_UPSTREAM as well, which will make this messy.  Can we check
CONFIG_CLK_EXYNOS and CONFIG_PINCTRL_EXYNOS instead?

>  #include 
> +#include 
>  #include 
> +#include 
>  #include "s3c24x0_i2c.h"
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -137,15 +141,26 @@ static int hsi2c_wait_for_trx(struct exynos5_hsi2c *i2c)
>   return I2C_NOK_TOUT;
>  }
>  
> -static int hsi2c_get_clk_details(struct s3c24x0_i2c_bus *i2c_bus)
> +static int hsi2c_get_clk_details(struct udevice *dev)
>  {
> + struct s3c24x0_i2c_bus *i2c_bus = dev_get_priv(dev);
>   struct exynos5_hsi2c *hsregs = i2c_bus->hsregs;
>   ulong clkin;
>   unsigned int op_clk = i2c_bus->clock_frequency;
>   unsigned int i = 0, utemp0 = 0, utemp1 = 0;
>   unsigned int t_ftl_cycle;
>  
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARCH_EXYNOS5)

As above, can we check CONFIG_CLK_EXYNOS instead?

>   clkin = get_i2c_clk();
> +#else
> + struct clk clk;
> + int ret;
> +
> + ret = clk_get_by_name(dev, "hsi2c", &clk);
> + if (ret < 0)
> + return ret;
> + clkin = clk_get_rate(&clk);
> +#endif
>   /* FPCLK / FI2C =
>* (CLK_DIV + 1) * (TSCLK_L + TSCLK_H + 2) + 8 + 2 * FLT_CYCLE
>* uTemp0 = (CLK_DIV + 1) * (TSCLK_L + TSCLK_H + 2)
> @@ -487,7 +502,7 @@ static int s3c24x0_i2c_set_bus_speed(struct udevice *dev, 
> unsigned int speed)
>  
>   i2c_bus->clock_frequency = speed;
>  
> - if (hsi2c_get_clk_details(i2c_bus))
> + if (hsi2c_get_clk_details(dev))
>   return -EFAULT;
>   hsi2c_ch_init(i2c_bus);
>  
> @@ -514,7 +529,9 @@ static int s3c24x0_i2c_probe(struct udevice *dev, uint 
> chip, uint chip_flags)
>  
>  static int s3c_i2c_of_to_plat(struct udevice *dev)
>  {
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARCH_EXYNOS5)
>   const void *blob = gd->fdt_blob;
> +#endif
>   struct s3c24x0_i2c_bus *i2c_bus = dev_get_priv(dev);
>   int node;
>  
> @@ -522,7 +539,9 @@ static int s3c_i2c_of_to_plat(struct udevice *dev)
>  
>   i2c_bus->hsregs = dev_read_addr_ptr(dev);
>  
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARCH_EXYNOS5)
>   i2c_bus->id = pinmux_decode_periph_id(blob, node);
> +#endif
>  
>   i2c_bus->clock_frequency =
>   dev_read_u32_default(dev, "clock-frequency",
> @@ -530,7 +549,9 @@ static int s3c_i2c_of_to_plat(struct udevice *dev)
>   i2c_bus->node = node;
>   i2c_bus->bus_num = dev_seq(dev);
>  
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARCH_EXYNOS5)
>   exynos_pinmux_config(i2c_bus->id, PINMUX_FLAG_HS_MODE);
> +#endif

I think these three #if def's can be consolidated in one #if def group
towards the end of s3c_i2c_of_to_plat to make it easier to follow.

Also, can we check CONFIG_PINCTRL_EXYNOS instead?  That would make it
easier when migrating Exynos 4 and 5 devices to pinctrl driver and
OF_UPSTREAM.

Same comments apply to s3c24x0_i2c.c below.

Best regards,
Henrik Grimler

>   i2c_bus->active = true;
>  
> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
> index ae3a801cad..ade1ad6cef 100644
> --- a/drivers/i2c/s3c24x0_i2c.c
> +++ b/drivers/i2c/s3c24x0_i2c.c
> @@ -9,12 +9,15 @@
>  #include 
>  #include 
>  #include 
> +#if IS_ENABLED(CONFIG_ARCH_EXYNOS4) || IS_ENABLED(CONFIG_ARC