Re: [PATCH] arm64: zynqmp: Do not describe u-boot.itb if SPL is disabled
On 3/5/24 16:47, Ilias Apalodimas wrote:
On Fri, Feb 23, 2024 at 05:18:42PM +0100, Michal Simek wrote:
There is no reason to describe u-boot.itb on system without SPL. Pretty
much this is cover all systems which are using only boot.bin which contains
all images inside.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 9641ed307b75..4f38b7d27684 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -43,7 +43,7 @@ struct efi_fw_image fw_images[] = {
.image_index = 1,
},
#endif
-#if defined(XILINX_UBOOT_IMAGE_GUID)
+#if defined(XILINX_UBOOT_IMAGE_GUID) &&
defined(CONFIG_SPL_FS_LOAD_PAYLOAD_NAME)
What happens if this is defined with CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" ?
Your comment is valid but I am not aware about any CONFIG_IS, etc which checks
that string is not empty. If name is "" it will return yes and second image is
doing to be defined.
But I found handling in the code like this.
36 #ifdef CONFIG_DEFAULT_FDT_FILE
37 if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
which can be used in my second patch not to describe second image in
set_dfu_alt_info() if string is empty.
Thanks,
Michal
Re: [PATCH 4/6] arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
On 3/4/24 02:01, Ilias Apalodimas wrote:
commit 47bd65ef057f ("arm: make __rel_dyn_{start, end} compiler-generated")
were moving the __rel_dyn_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so.
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section [0].
This have been fixed since 2016 [1]
[0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13
[1] commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared
object")
Signed-off-by: Ilias Apalodimas
Reviewed-by: Sam Edwards
Tested-by: Sam Edwards # Binary output identical
Thanks for the cleanup,
Sam
---
arch/arm/cpu/armv8/u-boot.lds | 16 +++-
arch/arm/cpu/u-boot.lds | 14 +++---
arch/arm/lib/sections.c | 2 --
arch/arm/mach-zynq/u-boot.lds | 14 +++---
4 files changed, 9 insertions(+), 37 deletions(-)
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index eccb116d3cfa..e737de761a9d 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -129,20 +129,10 @@ SECTIONS
*(.__image_copy_end)
}
- . = ALIGN(8);
-
- .rel_dyn_start :
- {
- *(.__rel_dyn_start)
- }
-
- .rela.dyn : {
+ .rela.dyn ALIGN(8) : {
+ __rel_dyn_start = .;
*(.rela*)
- }
-
- .rel_dyn_end :
- {
- *(.__rel_dyn_end)
+ __rel_dyn_end = .;
}
_end = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 70e78ce46672..7c6e7891d360 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -166,18 +166,10 @@ SECTIONS
*(.__image_copy_end)
}
- .rel_dyn_start :
- {
- *(.__rel_dyn_start)
- }
-
- .rel.dyn : {
+ .rel.dyn ALIGN(4) : {
+ __rel_dyn_start = .;
*(.rel*)
- }
-
- .rel_dyn_end :
- {
- *(.__rel_dyn_end)
+ __rel_dyn_end = .;
}
.end :
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index ddfde52163fc..1ee3dd3667ba 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -21,8 +21,6 @@
char __image_copy_start[0] __section(".__image_copy_start");
char __image_copy_end[0] __section(".__image_copy_end");
-char __rel_dyn_start[0] __section(".__rel_dyn_start");
-char __rel_dyn_end[0] __section(".__rel_dyn_end");
char __secure_start[0] __section(".__secure_start");
char __secure_end[0] __section(".__secure_end");
char __secure_stack_start[0] __section(".__secure_stack_start");
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 66a9e37f9198..71dea4a1f60a 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -71,18 +71,10 @@ SECTIONS
*(.__image_copy_end)
}
- .rel_dyn_start :
- {
- *(.__rel_dyn_start)
- }
-
- .rel.dyn : {
+ .rel.dyn ALIGN(8) : {
+ __rel_dyn_start = .;
*(.rel*)
- }
-
- .rel_dyn_end :
- {
- *(.__rel_dyn_end)
+ __rel_dyn_end = .;
}
.end :
Re: [PATCH 3/6] arm: fix __efi_runtime_rel_start/end definitions
On 3/4/24 02:01, Ilias Apalodimas wrote:
__efi_runtime_rel_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing. On top of that
the v8 linker scripts define it as a symbol.
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Sam Edwards
Tested-by: Sam Edwards # Binary output identical
Thanks for the cleanup,
Sam
---
arch/arm/cpu/armv8/u-boot.lds | 4 +---
arch/arm/cpu/u-boot.lds| 16 +++-
arch/arm/lib/sections.c| 2 --
arch/arm/mach-zynq/u-boot.lds | 16 +++-
include/asm-generic/sections.h | 2 ++
lib/efi_loader/efi_runtime.c | 1 +
6 files changed, 10 insertions(+), 31 deletions(-)
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index c4ee10ebc3ff..eccb116d3cfa 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -115,9 +115,7 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}
- . = ALIGN(8);
-
- .efi_runtime_rel : {
+ .efi_runtime_rel ALIGN(8) : {
__efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 90d329b1ebe0..70e78ce46672 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -152,21 +152,11 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}
- . = ALIGN(4);
-
- .efi_runtime_rel_start :
- {
- *(.__efi_runtime_rel_start)
- }
-
- .efi_runtime_rel : {
+ .efi_runtime_rel ALIGN(4) : {
+ __efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
- }
-
- .efi_runtime_rel_stop :
- {
- *(.__efi_runtime_rel_stop)
+ __efi_runtime_rel_stop = .;
}
. = ALIGN(4);
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 8e8bd5797e16..ddfde52163fc 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -29,6 +29,4 @@ char __secure_stack_start[0]
__section(".__secure_stack_start");
char __secure_stack_end[0] __section(".__secure_stack_end");
char __efi_runtime_start[0] __section(".__efi_runtime_start");
char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
-char __efi_runtime_rel_start[0] __section(".__efi_runtime_rel_start");
-char __efi_runtime_rel_stop[0] __section(".__efi_runtime_rel_stop");
char _end[0] __section(".__end");
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 8d3259821719..66a9e37f9198 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -58,21 +58,11 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}
- . = ALIGN(4);
-
- .efi_runtime_rel_start :
- {
- *(.__efi_runtime_rel_start)
- }
-
- .efi_runtime_rel : {
+ .efi_runtime_rel ALIGN(4) : {
+ __efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
- }
-
- .efi_runtime_rel_stop :
- {
- *(.__efi_runtime_rel_stop)
+ __efi_runtime_rel_stop = .;
}
. = ALIGN(8);
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 1e1657a01673..60949200dd93 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -34,6 +34,8 @@ extern char __priv_data_start[], __priv_data_end[];
/* Start and end of .ctors section - used for constructor calls. */
extern char __ctors_start[], __ctors_end[];
+extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
+
/* function descriptor handling (if any). Override
* in asm/sections.h */
#ifndef dereference_function_descriptor
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 18da6892e796..9185f1894c47 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
/* For manual relocation support */
DECLARE_GLOBAL_DATA_PTR;
Re: [PATCH 2/6] arm: clean up v7 and v8 linker scripts for bss_start/end
On 3/4/24 02:01, Ilias Apalodimas wrote:
commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so.
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section.
This have been fixed since 2016 [1]. So let's start cleaning this up
starting with the bss_start and bss_end variables. Convert them into
symbols within the .bss section definition.
[0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13
[1] commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared
object")
Signed-off-by: Ilias Apalodimas
Tested-by: Caleb Connolly # Qualcomm sdm845
---
arch/arm/cpu/armv8/u-boot-spl.lds| 14 +++---
arch/arm/cpu/armv8/u-boot.lds| 15 +++
arch/arm/cpu/u-boot.lds | 22 --
arch/arm/lib/sections.c | 2 --
arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 14 +++---
arch/arm/mach-zynq/u-boot.lds| 21 +++--
6 files changed, 16 insertions(+), 72 deletions(-)
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds
b/arch/arm/cpu/armv8/u-boot-spl.lds
index 7cb9d731246d..16fddb46e9cb 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -63,18 +63,10 @@ SECTIONS
_image_binary_end = .;
- .bss_start (NOLOAD) : {
- . = ALIGN(8);
- KEEP(*(.__bss_start));
- } >.sdram
-
- .bss (NOLOAD) : {
+ .bss : {
+ __bss_start = .;
*(.bss*)
-. = ALIGN(8);
- } >.sdram
-
- .bss_end (NOLOAD) : {
- KEEP(*(.__bss_end));
+ __bss_end = .;
} >.sdram
/DISCARD/ : { *(.rela*) }
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fb6a30c922f7..c4ee10ebc3ff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -149,19 +149,10 @@ SECTIONS
_end = .;
- . = ALIGN(8);
-
- .bss_start : {
- KEEP(*(.__bss_start));
- }
-
- .bss : {
+ .bss ALIGN(8): {
+ __bss_start = .;
*(.bss*)
-. = ALIGN(8);
- }
-
- .bss_end : {
- KEEP(*(.__bss_end));
+ __bss_end = .;
}
/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 7724c9332c3b..90d329b1ebe0 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -206,27 +206,13 @@ SECTIONS
*(.mmutable)
}
-/*
- * Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
- * __bss_base and __bss_limit are for linker only (overlay ordering)
- */
-
- .bss_start __rel_dyn_start (OVERLAY) : {
- KEEP(*(.__bss_start));
- __bss_base = .;
- }
-
- .bss __bss_base (OVERLAY) : {
+ .bss ALIGN(4): {
Hi Ilias,
I have been reviewing this patchset by diffing output binaries and
linker maps between successive patches. Most of the patches in this
series result in no change to the output binary whatsoever (which also
means, no regressions!) but this one does have a change: .bss is being
moved after .mmutable. You should be able to see this yourself by
comparing `u-boot.map` after a successful build, before and after
applying this patch.
Since the current u-boot.lds puts .bss right after __image_copy_end
(which makes sense) and uses OVERLAY to overlap .rel.dyn (which... I
guess makes sense, if U-Boot zero-initializes .bss after applying
relocations), perhaps this patch should be moving the .bss section up
there in the .lds, putting (OVERLAY) back, and adding a comment to the
effect of "These sections occupy the same memory, but their lifetimes do
not overlap: U-Boot initializes .bss only after applying relocations and
therefore after it doesn't need .rel.dyn any more."
We might also decide that the overlay memory-saving trick isn't actually
all that important anymore and that .bss should have a new home. Someone
far more seasoned than I should be the one to make that decision though.
The rest of the patchset looks great! I'll add my tags to those in a bit.
Cheers,
Sam
+ __bss_start = .;
*(.bss*)
-. = ALIGN(4);
-__bss_limit = .;
- }
-
- .bss_end __bss_limit (OVERLAY) : {
- KEEP(*(.__bss_end));
+ __bss_end = .;
}
- .dynsym _image_binary_end : { *(.dynsym) }
+
Re: [PATCH v2 5/8] phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
On Wed, 6 Mar 2024 at 06:17, Adam Ford wrote:
>
> On Tue, Mar 5, 2024 at 7:51 AM Adam Ford wrote:
> >
> > On Tue, Mar 5, 2024 at 7:48 AM Sumit Garg wrote:
> > >
> > > Hi Adam,
> > >
> > > On Wed, 28 Feb 2024 at 12:29, Sumit Garg wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > On Wed, 28 Feb 2024 at 04:42, Adam Ford wrote:
> > > > >
> > > > > On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg
> > > > > wrote:
> > > > > >
> > > > > > Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs
> > > > > > PCIe
> > > > > > PHY initialization moved to this standalone PHY driver.
> > > > > >
> > > > > > Inspired from counterpart Linux kernel v6.8-rc3 driver:
> > > > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c.
> > > > >
> > > > > I have a PCIe device that works just fine in Linux. I have applied
> > > > > your series an enabled the same config options as you did along with
> > > > > some others to resolve some build issues.
> > > > >
> > > > > Any ideas how to address:
> > > > >
> > > > > nxp_imx8_pcie_phy pcie-phy@32f0: PHY: Failed to power on
> > > > > pcie-phy@32f0: -110.
> > > > >
> > > > > My PHY node looks like this
> > > > >
> > > > > _phy {
> > > > > fsl,refclk-pad-mode = ;
> > > > > clocks = <_refclk>;
> > > > > clock-names = "ref";
> > > > > status = "okay";
> > > > > };
> > > > >
> > > > > The pcie_refcllk is defined as a 100MHz fixed clock in U-Boot. clk
> > > > > dump shows it to be:
> > > > >
> > > > > 10|-- clock-pcie
> > > > >
> > > >
> > > > I suppose that's an EVK board, try enabling MPCIE_3V3 regulator
> > > > required for EVK board via following patch:
> > > >
> > > > diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> > > > index 7856823c9188..32fd2cb05d4b 100644
> > > > --- a/drivers/pci/pcie_dw_imx.c
> > > > +++ b/drivers/pci/pcie_dw_imx.c
> > > > @@ -17,6 +17,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -158,6 +159,8 @@ static int pcie_dw_imx_probe(struct udevice *dev)
> > > > struct pci_controller *hose = dev_get_uclass_priv(ctlr);
> > > > int ret;
> > > >
> > > > + regulator_autoset_by_name("MPCIE_3V3", NULL);
>
> I think you should search the device tree for "vpcie-supply" and
> enable the corresponding regulator, because is more flexible than
> hard-coding regulator names. This is also more of a standard practice.
>
Yeah I agree, this was sort of a minimal diff to test with.
> > > > +
> > > > ret = imx_pcie_assert_core_reset(priv);
> > > > if (ret) {
> > > > dev_err(dev, "failed to assert core reset\n");
> > > >
> > >
> > > Were you able to give a retry with the above diff?
> >
> > Not yet, but I'll try to do it tonight.
>
> That didn't work for me. I am using a Beacon Embedded kit which does
> not use a regulator, so this had no impact, but I think having the
> vpcie-supply regulator is a good idea.
Sure, I can add that.
-Sumit
>
> I'll investigate a bit more and let you know if I make any progress.
>
> adam
> >
> > adam
> > >
> > > -Sumit
Re: [PATCH v2 6/8] pinctrl: qcom: pass pin number to get_function_mux callback
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> This patch is the preparation for SM8150 support. This new SoC
> depending on the particular pin can have different numbers for the
> same function. For example "rgmii" function for GPIO4 has id=2 while
> for GPIO59 it has id=1. So, to support this type of SoCs,
> get_function_mux() callback needs to know for which pin the function
> is requested.
>
> Signed-off-by: Volodymyr Babchuk
> Reviewed-by: Caleb Connolly
>
> ---
>
> Changes in v2:
> - Added Caleb's R-b tag
>
> drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-qcom.c| 4 ++--
> drivers/pinctrl/qcom/pinctrl-qcom.h| 3 ++-
> drivers/pinctrl/qcom/pinctrl-qcs404.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-sdm845.c | 3 ++-
> 7 files changed, 14 insertions(+), 8 deletions(-)
>
Reviewed-by: Sumit Garg
-Sumit
> diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
> b/drivers/pinctrl/qcom/pinctrl-apq8016.c
> index db0e212468..a9a00f4b08 100644
> --- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
> +++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
> @@ -49,7 +49,8 @@ static const char *apq8016_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int apq8016_get_function_mux(unsigned int selector)
> +static unsigned int apq8016_get_function_mux(__maybe_unused unsigned int pin,
> +unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-apq8096.c
> b/drivers/pinctrl/qcom/pinctrl-apq8096.c
> index 880df8fe3c..9697cb5beb 100644
> --- a/drivers/pinctrl/qcom/pinctrl-apq8096.c
> +++ b/drivers/pinctrl/qcom/pinctrl-apq8096.c
> @@ -44,7 +44,8 @@ static const char *apq8096_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int apq8096_get_function_mux(unsigned int selector)
> +static unsigned int apq8096_get_function_mux(__maybe_unused unsigned int pin,
> +unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> index 74c04ab87c..4479230313 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> @@ -40,7 +40,8 @@ static const char *ipq4019_get_pin_name(struct udevice *dev,
> return pin_name;
> }
>
> -static unsigned int ipq4019_get_function_mux(unsigned int selector)
> +static unsigned int ipq4019_get_function_mux(__maybe_unused unsigned int pin,
> +unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c
> b/drivers/pinctrl/qcom/pinctrl-qcom.c
> index ee0624df29..909e566acf 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
> @@ -83,14 +83,14 @@ static int msm_pinmux_set(struct udevice *dev, unsigned
> int pin_selector,
> unsigned int func_selector)
> {
> struct msm_pinctrl_priv *priv = dev_get_priv(dev);
> + u32 func = priv->data->get_function_mux(pin_selector, func_selector);
>
> /* Always NOP for special pins, assume they're in the correct state */
> if (qcom_is_special_pin(>data->pin_data, pin_selector))
> return 0;
>
> clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
> - TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE,
> - priv->data->get_function_mux(func_selector) << 2);
> + TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
> return 0;
> }
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.h
> b/drivers/pinctrl/qcom/pinctrl-qcom.h
> index 07f2eae9ba..49b7bfbc00 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.h
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.h
> @@ -18,7 +18,8 @@ struct msm_pinctrl_data {
> int functions_count;
> const char *(*get_function_name)(struct udevice *dev,
> unsigned int selector);
> - unsigned int (*get_function_mux)(unsigned int selector);
> + unsigned int (*get_function_mux)(unsigned int pin,
> +unsigned int selector);
> const char *(*get_pin_name)(struct udevice *dev,
> unsigned int selector);
> };
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcs404.c
> b/drivers/pinctrl/qcom/pinctrl-qcs404.c
> index 3a2d468599..4b7c670c90 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcs404.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcs404.c
> @@ -94,7 +94,8 @@ static const char *qcs404_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int qcs404_get_function_mux(unsigned int
Re: [PATCH v2 5/8] clk: qcom: add driver for SM8150 SoC
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> Add clock, reset and power domain driver for SM8150. Driver code is
> based on the similar U-Boot drivers. All constants are taken from the
> corresponding Linux driver.
>
> This driver supports clock rate setting only for the debug UART and
> RGMII/Ethernet modules, because this is all I can test right now.
>
> Signed-off-by: Volodymyr Babchuk
>
> ---
>
> Changes in v2:
> - Renamed GPLL7_MAIN to just GPLL7 (while I like idea to use Linux
>naming convention, such rework needs to be done in a separate
>commit)
> - Removed unnecessary include
> - Fixed GDSCR register values for couple of devices
> - Enable GPLL7 only when RGMII clock is enabled
>
> drivers/clk/qcom/Kconfig| 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clock-qcom.h | 1 +
> drivers/clk/qcom/clock-sm8150.c | 237
> 4 files changed, 247 insertions(+)
> create mode 100644 drivers/clk/qcom/clock-sm8150.c
>
Reviewed-by: Sumit Garg
-Sumit
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 0df0d1881a..18ccf6a45e 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
> on the Snapdragon 845 SoC. This driver supports the clocks
> and resets exposed by the GCC hardware block.
>
> +config CLK_QCOM_SM8150
> + bool "Qualcomm SM8150 GCC"
> + select CLK_QCOM
> + help
> + Say Y here to enable support for the Global Clock Controller
> + on the Snapdragon 8150 SoC. This driver supports the clocks
> + and resets exposed by the GCC hardware block.
> +
> endmenu
>
> endif
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index cb179fdac5..12c09ba19e 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
> obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
> obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
> obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
> +obj-$(CONFIG_CLK_QCOM_SM8150) += clock-sm8150.o
> diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
> index 12a1eaec2b..dd40487e94 100644
> --- a/drivers/clk/qcom/clock-qcom.h
> +++ b/drivers/clk/qcom/clock-qcom.h
> @@ -9,6 +9,7 @@
>
> #define CFG_CLK_SRC_CXO (0 << 8)
> #define CFG_CLK_SRC_GPLL0 (1 << 8)
> +#define CFG_CLK_SRC_GPLL7 (3 << 8)
> #define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
> #define CFG_CLK_SRC_MASK (7 << 8)
>
> diff --git a/drivers/clk/qcom/clock-sm8150.c b/drivers/clk/qcom/clock-sm8150.c
> new file mode 100644
> index 00..2592eef29b
> --- /dev/null
> +++ b/drivers/clk/qcom/clock-sm8150.c
> @@ -0,0 +1,237 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Clock drivers for Qualcomm SM8150
> + *
> + * Volodymyr Babchuk
> + * Copyright (c) 2024 EPAM Systems.
> + *
> + * Based on U-Boot driver for SDM845. Constants are taken from the Linux
> driver.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clock-qcom.h"
> +
> +static struct pll_vote_clk gpll7_vote_clk = {
> + .status = 0x1a000,
> + .status_bit = BIT(31),
> + .ena_vote = 0x52000,
> + .vote_bit = BIT(7),
> +};
> +
> +static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
> + F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> + F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> + F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> + F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> + F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> + F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> + F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> + F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> + F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> + F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
> + F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
> + F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
> + F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
> + F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
> + F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
> + { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_emac_rgmii_clk_src[] = {
> + F(250, CFG_CLK_SRC_CXO, 1, 25, 192),
> + F(500, CFG_CLK_SRC_CXO, 1, 25, 96),
> + F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> + F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
> + F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
> + F(12500, CFG_CLK_SRC_GPLL7, 4, 0, 0),
> + F(25000, CFG_CLK_SRC_GPLL7, 2, 0, 0),
> + { }
> +};
> +
> +static const struct bcr_regs uart2_regs = {
> + .cfg_rcgr = 0x1814C,
> + .cmd_rcgr = 0x18148,
> + .M = 0x18150,
> + .N = 0x18154,
> + .D = 0x18158,
> +};
> +
> +static const
Re: [PATCH v2 4/8] clk: qcom: add support for power domains uclass
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> Now sub-drivers for particular SoCs can register them as power domain
> drivers. This is needed for upcoming SM8150 support, because it needs
> to power up the Ethernet module.
>
> Signed-off-by: Volodymyr Babchuk
>
> ---
>
> Changes in v2:
> - Reworked qcom_cc_bind() function
> - Added timeout to qcom_power_set()
> - Minor fixes in register names and formatting
>
> drivers/clk/qcom/clock-qcom.c | 128 ++
> drivers/clk/qcom/clock-qcom.h | 6 ++
> 2 files changed, 121 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
> index 729d190c54..c3f8d96183 100644
> --- a/drivers/clk/qcom/clock-qcom.c
> +++ b/drivers/clk/qcom/clock-qcom.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include "clock-qcom.h"
>
> @@ -30,6 +31,13 @@
> #define CBCR_BRANCH_ENABLE_BIT BIT(0)
> #define CBCR_BRANCH_OFF_BIT BIT(31)
>
> +#define GDSC_SW_COLLAPSE_MASK BIT(0)
> +#define GDSC_POWER_DOWN_COMPLETE BIT(15)
> +#define GDSC_POWER_UP_COMPLETE BIT(16)
> +#define GDSC_PWR_ON_MASK BIT(31)
> +#define CFG_GDSCR_OFFSET 0x4
> +#define GDSC_STATUS_POLL_TIMEOUT_US1500
> +
> /* Enable clock controlled by CBC soft macro */
> void clk_enable_cbc(phys_addr_t cbcr)
> {
> @@ -223,7 +231,7 @@ U_BOOT_DRIVER(qcom_clk) = {
> int qcom_cc_bind(struct udevice *parent)
> {
> struct msm_clk_data *data = (struct msm_clk_data
> *)dev_get_driver_data(parent);
> - struct udevice *clkdev, *rstdev;
> + struct udevice *clkdev = NULL, *rstdev = NULL, *pwrdev;
> struct driver *drv;
> int ret;
>
> @@ -238,20 +246,41 @@ int qcom_cc_bind(struct udevice *parent)
> if (ret)
> return ret;
>
> - /* Bail out early if resets are not specified for this platform */
> - if (!data->resets)
> - return ret;
> + if (data->resets) {
> + /* Get a handle to the common reset handler */
> + drv = lists_driver_lookup_name("qcom_reset");
> + if (!drv) {
> + ret = -ENOENT;
> + goto unbind_clkdev;
> + }
> +
> + /* Register the reset controller */
> + ret = device_bind_with_driver_data(parent, drv, "qcom_reset",
> (ulong)data,
> + dev_ofnode(parent),
> );
> + if (ret)
> + goto unbind_clkdev;
> + }
>
> - /* Get a handle to the common reset handler */
> - drv = lists_driver_lookup_name("qcom_reset");
> - if (!drv)
> - return -ENOENT;
> + if (data->power_domains) {
> + /* Get a handle to the common power domain handler */
> + drv = lists_driver_lookup_name("qcom_power");
> + if (!drv) {
> + ret = -ENOENT;
> + goto unbind_rstdev;
> + }
> + /* Register the power domain controller */
> + ret = device_bind_with_driver_data(parent, drv, "qcom_power",
> (ulong)data,
> + dev_ofnode(parent),
> );
> + if (ret)
> + goto unbind_rstdev;
> + }
>
> - /* Register the reset controller */
> - ret = device_bind_with_driver_data(parent, drv, "qcom_reset",
> (ulong)data,
> - dev_ofnode(parent), );
> - if (ret)
> - device_unbind(clkdev);
> + return 0;
> +
> +unbind_rstdev:
> + device_unbind(rstdev);
> +unbind_clkdev:
> + device_unbind(clkdev);
>
> return ret;
> }
> @@ -306,3 +335,76 @@ U_BOOT_DRIVER(qcom_reset) = {
> .ops = _reset_ops,
> .probe = qcom_reset_probe,
> };
> +
> +static int qcom_power_set(struct power_domain *pwr, bool on)
> +{
> + struct msm_clk_data *data = (struct msm_clk_data
> *)dev_get_driver_data(pwr->dev);
> + void __iomem *base = dev_get_priv(pwr->dev);
> + unsigned long timeout;
> + const struct qcom_power_map *map;
> + u32 value;
> +
> + if (pwr->id >= data->num_power_domains)
> + return -ENODEV;
> +
> + map = >power_domains[pwr->id];
> +
> + if (!map->reg)
> + return -ENODEV;
> +
> + value = readl(base + map->reg);
> +
> + if (on)
> + value &= ~GDSC_SW_COLLAPSE_MASK;
> + else
> + value |= GDSC_SW_COLLAPSE_MASK;
> +
> + writel(value, base + map->reg);
> +
> + timeout = timer_get_us() + GDSC_STATUS_POLL_TIMEOUT_US;
> + /* Wait for power on */
> + while (timeout > timer_get_us()) {
> + value = readl(base + map->reg + CFG_GDSCR_OFFSET);
You should be able to reuse readl_poll_timeout() here instead.
-Sumit
[PATCH] board: developerbox: fix mem_map setup timing
The setup of global variable mem_map was moved into enable_caches()
by commit a70c75cabae1 ("board: developerbox: move mem_map setup later")
since U-Boot was directly booted from NOR flash in XIP
and bss is not yet available in dram_init() at that time.
This has a problem, mem_map variable is used by
the get_page_table_size() to calculate the page table size,
but get_page_table_size() is called earlier than enable_caches()
which fills mem_map variable. With that, U-Boot fails to boot when
64GB DIMM is installed.
Currently U-Boot on the Developerbox board is not booted in XIP
and bss is available in dram_init(), let's move mem_map setup
in dram_init().
Signed-off-by: Masahisa Kojima
---
board/socionext/developerbox/developerbox.c | 60 -
1 file changed, 21 insertions(+), 39 deletions(-)
diff --git a/board/socionext/developerbox/developerbox.c
b/board/socionext/developerbox/developerbox.c
index ac4415ff3b..062e4a7b79 100644
--- a/board/socionext/developerbox/developerbox.c
+++ b/board/socionext/developerbox/developerbox.c
@@ -125,10 +125,29 @@ int dram_init(void)
struct draminfo *synquacer_draminfo = (void *)SQ_DRAMINFO_BASE;
struct draminfo_entry *ent = synquacer_draminfo->entry;
unsigned long size = 0;
- int i;
+ struct mm_region *mr;
+ int i, ri;
+
+ if (synquacer_draminfo->nr_regions < 1) {
+ log_err("Failed to get correct DRAM information\n");
+ return -EINVAL;
+ }
- for (i = 0; i < synquacer_draminfo->nr_regions; i++)
+ for (i = 0; i < synquacer_draminfo->nr_regions; i++) {
+ if (i >= MAX_DDR_REGIONS)
+ break;
+
+ ri = DDR_REGION_INDEX(i);
+ mem_map[ri].phys = ent[i].base;
+ mem_map[ri].size = ent[i].size;
+ mem_map[ri].virt = mem_map[ri].phys;
size += ent[i].size;
+ if (i == 0)
+ continue;
+
+ mr = _map[DDR_REGION_INDEX(0)];
+ mem_map[ri].attrs = mr->attrs;
+ }
gd->ram_size = size;
gd->ram_base = ent[0].base;
@@ -162,43 +181,6 @@ int dram_init_banksize(void)
return 0;
}
-void build_mem_map(void)
-{
- struct draminfo *synquacer_draminfo = (void *)SQ_DRAMINFO_BASE;
- struct draminfo_entry *ent = synquacer_draminfo->entry;
- struct mm_region *mr;
- int i, ri;
-
- if (synquacer_draminfo->nr_regions < 1) {
- log_err("Failed to get correct DRAM information\n");
- return;
- }
-
- /* Update memory region maps */
- for (i = 0; i < synquacer_draminfo->nr_regions; i++) {
- if (i >= MAX_DDR_REGIONS)
- break;
-
- ri = DDR_REGION_INDEX(i);
- mem_map[ri].phys = ent[i].base;
- mem_map[ri].size = ent[i].size;
- mem_map[ri].virt = mem_map[ri].phys;
- if (i == 0)
- continue;
-
- mr = _map[DDR_REGION_INDEX(0)];
- mem_map[ri].attrs = mr->attrs;
- }
-}
-
-void enable_caches(void)
-{
- build_mem_map();
-
- icache_enable();
- dcache_enable();
-}
-
int print_cpuinfo(void)
{
printf("CPU: SC2A11:Cortex-A53 MPCore 24cores\n");
--
2.34.1
Re: [PATCH v2 3/8] net: dw_eth_qos: add support for Qualcomm SM8150 SoC
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> Add support for Qualcomm SM8150 SoC to the EQOS driver. SM8150 has two
> main differences from already supported QCS404: it has another RGMII
> configuration registers set and it does require RGMII loopback to
> be disabled.
>
> To support different variants of QCOM SoC we had to add two new fields
> to the eqos_priv struct: eqos_qcom_rgmii_regs and
> qcom_enable_loopback.
>
> Signed-off-by: Volodymyr Babchuk
>
> ---
>
> Changes in v2:
> - Clear loopback bit explicitly
>
> drivers/net/dwc_eth_qos.c | 4 +++
> drivers/net/dwc_eth_qos.h | 2 ++
> drivers/net/dwc_eth_qos_qcom.c | 46 +++---
> 3 files changed, 43 insertions(+), 9 deletions(-)
>
Reviewed-by: Sumit Garg
-Sumit
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 9b3bce1dc8..882b854697 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -1700,6 +1700,10 @@ static const struct udevice_id eqos_ids[] = {
> .compatible = "qcom,qcs404-ethqos",
> .data = (ulong)_qcom_config
> },
> + {
> + .compatible = "qcom,sm8150-ethqos",
> + .data = (ulong)_qcom_config
> + },
> #endif
> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STARFIVE)
> {
> diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
> index e3222e1e17..216e1afe53 100644
> --- a/drivers/net/dwc_eth_qos.h
> +++ b/drivers/net/dwc_eth_qos.h
> @@ -255,6 +255,7 @@ struct eqos_priv {
> struct eqos_dma_regs *dma_regs;
> struct eqos_tegra186_regs *tegra186_regs;
> void *eqos_qcom_rgmii_regs;
> + struct dwmac_rgmii_regs *eqos_qcom_por;
> struct reset_ctl reset_ctl;
> struct gpio_desc phy_reset_gpio;
> struct clk clk_master_bus;
> @@ -277,6 +278,7 @@ struct eqos_priv {
> bool started;
> bool reg_access_ok;
> bool clk_ck_enabled;
> + bool qcom_enable_loopback;
> unsigned int tx_fifo_sz, rx_fifo_sz;
> u32 reset_delays[3];
> };
> diff --git a/drivers/net/dwc_eth_qos_qcom.c b/drivers/net/dwc_eth_qos_qcom.c
> index 8178138fc6..ee8420c71d 100644
> --- a/drivers/net/dwc_eth_qos_qcom.c
> +++ b/drivers/net/dwc_eth_qos_qcom.c
> @@ -95,6 +95,15 @@ static struct dwmac_rgmii_regs emac_v2_3_0_por = {
> .io_macro_config2 = 0x2060
> };
>
> +static struct dwmac_rgmii_regs emac_v2_1_0_por = {
> + .io_macro_config = 0x40C01343,
> + .sdcc_hc_dll_config = 0x2004642C,
> + .sdcc_hc_ddr_config = 0x,
> + .sdcc_hc_dll_config2 = 0x0020,
> + .sdcc_usr_ctl = 0x00010800,
> + .io_macro_config2 = 0x2060
> +};
> +
> static void ethqos_set_func_clk_en(struct dwmac_rgmii_regs *regs)
> {
> setbits_le32(>io_macro_config, RGMII_CONFIG_FUNC_CLK_EN);
> @@ -172,6 +181,10 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
>struct dwmac_rgmii_regs *regs,
>unsigned long speed)
> {
> + struct eqos_priv *eqos = dev_get_priv(dev);
> + uint32_t loopback =
> + eqos->qcom_enable_loopback ? RGMII_CONFIG_LOOPBACK_EN : 0;
> +
> /* Disable loopback mode */
> clrbits_le32(>io_macro_config2,
> RGMII_CONFIG2_TX_TO_RX_LOOPBACK_EN);
> @@ -202,7 +215,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
> SDCC_DDR_CONFIG_PRG_RCLK_DLY, 57);
> setbits_le32(>sdcc_hc_ddr_config,
> SDCC_DDR_CONFIG_PRG_DLY_EN);
>
> - setbits_le32(>io_macro_config,
> RGMII_CONFIG_LOOPBACK_EN);
> + clrsetbits_le32(>io_macro_config,
> + RGMII_CONFIG_LOOPBACK_EN, loopback);
> break;
>
> case SPEED_100:
> @@ -233,7 +247,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
> setbits_le32(>sdcc_hc_ddr_config,
> SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
>
> - setbits_le32(>io_macro_config,
> RGMII_CONFIG_LOOPBACK_EN);
> + clrsetbits_le32(>io_macro_config,
> + RGMII_CONFIG_LOOPBACK_EN, loopback);
> break;
>
> case SPEED_10:
> @@ -265,7 +280,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
> setbits_le32(>sdcc_hc_ddr_config,
> SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
>
> - setbits_le32(>io_macro_config,
> RGMII_CONFIG_LOOPBACK_EN);
> + clrsetbits_le32(>io_macro_config,
> + RGMII_CONFIG_LOOPBACK_EN, loopback);
> break;
>
> default:
> @@ -281,14 +297,15 @@ static int ethqos_configure(struct udevice *dev,
> unsigned long speed)
> {
> unsigned int retry = 1000;
> + struct eqos_priv *eqos =
Re: [PATCH v2 2/8] clk: qcom: clear div mask before assigning a new divider
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk wrote: > > The current behaviour does a bitwise OR of the previous and new > divider values, this is wrong as some bits maybe be set already. We > need to clear all the divider bits before applying new ones. > > This fixes potential issue with 1Gbit ethernet on SA8155P-ADP boards. > > Signed-off-by: Volodymyr Babchuk > Reviewed-by: Caleb Connolly > > --- > > Changes in v2: > - Reworded the commit message > - Added Caleb's R-b tag > > drivers/clk/qcom/clock-qcom.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Sumit Garg -Sumit > diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c > index 7c683e5192..729d190c54 100644 > --- a/drivers/clk/qcom/clock-qcom.c > +++ b/drivers/clk/qcom/clock-qcom.c > @@ -117,7 +117,8 @@ void clk_rcg_set_rate_mnd(phys_addr_t base, const struct > bcr_regs *regs, > > /* setup src select and divider */ > cfg = readl(base + regs->cfg_rcgr); > - cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK); > + cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK | > +CFG_SRC_DIV_MASK); > cfg |= source & CFG_SRC_SEL_MASK; /* Select clock source */ > > if (div) > -- > 2.43.0
Re: [PATCH v2 1/8] qcom: board: validate fdt before trying to use it
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> There are cases when previous bootloader stage leaves some seemingly
> valid value in r0, which in fact does not point to valid FDT
> blob. This behavior was encountered when trying to boot U-Boot as
> "hyp" loader on SA8155P-ADP.
>
> To be sure that we really got the pointer to a device tree we need to
> validate it with fdt_valid() function.
>
> Note: This approach is not 100% fool-proof, as get_prev_bl_fdt_addr()
> theoretically can return a pointer to a region that is not physically
> mapped and we will get data abort exception when "fdt_valid" will try
> to access it. But at this early boot stage we don't know where RAM is
> anyways so there is little we can do.
>
I suppose this approach allows us to reuse the same U-Boot binary when
booted in EL2 more or when loaded by ABL. So I am fine with this
approach.
Reviewed-by: Sumit Garg
-Sumit
> Signed-off-by: Volodymyr Babchuk
>
> ---
>
> Changes in v2:
> - New patch in v2
>
> arch/arm/mach-snapdragon/board.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-snapdragon/board.c
> b/arch/arm/mach-snapdragon/board.c
> index f12f5791a1..10eec47ada 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -93,7 +94,9 @@ void *board_fdt_blob_setup(int *err)
> * try and use the FDT built into U-Boot if there is one...
> * This avoids having a hard dependency on the previous stage
> bootloader
> */
> - if (IS_ENABLED(CONFIG_OF_SEPARATE) && (!fdt || fdt != ALIGN(fdt,
> SZ_4K))) {
> +
> + if (IS_ENABLED(CONFIG_OF_SEPARATE) && (!fdt || fdt != ALIGN(fdt,
> SZ_4K) ||
> + !fdt_valid((void * {
> debug("%s: Using built in FDT, bootloader gave us %#llx\n",
> __func__, fdt);
> return (void *)gd->fdt_blob;
> }
> --
> 2.43.0
Re: [PATCH v2 8/8] board: add support for Qualcomm SA8155P-ADP board
Hi Volodymyr,
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
wrote:
>
> SA8155P Automotive Development Platform is Qualcomm SA8155-based board
> for developers. The nice thing that it has unlocked loaders with test
> keys support, which means that U-Boot for this platform can be
> launched at earlier stages.
>
> This patch adds basic board support with only serial port and
> networking operation. I am using U-Boot to ease up Xen porting onto
> this board, so I am mostly interesting in booting U-Boot in EL2. But
> more conventional setup with Android boot image is supported as well.
>
> Signed-off-by: Volodymyr Babchuk
>
> ---
>
> Changes in v2:
> - Rebased onto qcom-next branch
> - Removed unnecessary files thanks to generic qualcomm board support
> - Enabled CONFIG_REMAKE_ELF (this removes one extra step in the
>readme)
Thanks for the rebase.
>
> arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 +
> board/qualcomm/sa8155p-adp/MAINTAINERS | 5 ++
> configs/sa8155p_adp_defconfig | 35 +++
> doc/board/qualcomm/index.rst | 1 +
> doc/board/qualcomm/sa8155p-adp.rst | 87 ++
> 5 files changed, 158 insertions(+)
> create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
> create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
> create mode 100644 configs/sa8155p_adp_defconfig
> create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
>
> diff --git a/arch/arm/dts/sa8155p-adp-u-boot.dtsi
> b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
> new file mode 100644
> index 00..ffbf0933c7
> --- /dev/null
> +++ b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Qualcomm SA8155P-ADP device tree fixups for U-BOot
> + *
> + * Volodymyr Babchuk
> + * Copyright (c) 2024 EPAM Systems.
> + */
> +
> +/ {
> + /* Populate memory node with actual memory configuration */
> + memory@8000 {
> + reg = <0x00 0x8000 0x00 0x3990>,
> + <0x02 0x00x1 0x7fd0>,
> + <0x00 0xC000 0x1 0x4000>;
> + };
> +};
> +
> + {
> + /* Ethernet driver tries to find reset by name */
> + reset-names = "emac";
This deserves to be pushed upstream in Linux kernel DT. In the
meantime we can carry it here.
> +};
> +
> + {
> + /* U-Boot pinctrl driver does not understand multiple tiles */
> + reg = <0x0 0x0300 0x0 0x100>;
> + /delete-property/ reg-names;
This won't be needed if we can make the tiles offset in the pinctrl
driver compatible:
#define WEST 0x
#define EAST 0x0040
#define NORTH 0x0080
#define SOUTH 0x00C0
> +
> + /* U-Boot ethernet driver wants to drive reset as GPIO */
> + /delete-node/ phy-reset-pins;
I suppose this is not needed as phy-reset-pins also configures the pin
as GPIO only.
> +};
> diff --git a/board/qualcomm/sa8155p-adp/MAINTAINERS
> b/board/qualcomm/sa8155p-adp/MAINTAINERS
> new file mode 100644
> index 00..03fac84f51
> --- /dev/null
> +++ b/board/qualcomm/sa8155p-adp/MAINTAINERS
> @@ -0,0 +1,5 @@
> +Qualcomm SA8155P Automotive Development Platform
> +M: Volodymyr Babchuk
> +S: Maintained
> +F: board/qualcomm/sa8155p-adp/
> +F: configs/sa8155p-adp_defconfig
> diff --git a/configs/sa8155p_adp_defconfig b/configs/sa8155p_adp_defconfig
> new file mode 100644
> index 00..b6969767f8
> --- /dev/null
> +++ b/configs/sa8155p_adp_defconfig
> @@ -0,0 +1,35 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=1900
> +CONFIG_POSITION_INDEPENDENT=y
> +CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
> +CONFIG_ARCH_SNAPDRAGON=y
> +CONFIG_TEXT_BASE=0x8571
Being position independent shouldn't require a hardcoded U-Boot text
base. Can you try if we can get rid of this?
> +CONFIG_DEFAULT_DEVICE_TREE="qcom/sa8155p-adp"
> +CONFIG_IDENT_STRING="\nQualcomm SA8155P-ADP"
> +CONFIG_SYS_LOAD_ADDR=0x8571
Ditto.
> +CONFIG_REMAKE_ELF=y
> +CONFIG_BOOTDELAY=3
> +CONFIG_SYS_CBSIZE=512
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_HUSH_PARSER=y
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_CLK=y
> +CONFIG_CLK_QCOM_SM8150=y
> +CONFIG_MSM_GPIO=y
> +CONFIG_PHY_MICREL=y
> +CONFIG_PHY_MICREL_KSZ90X1=y
> +CONFIG_DM_MDIO=y
> +CONFIG_DM_ETH_PHY=y
> +CONFIG_DWC_ETH_QOS=y
> +CONFIG_DWC_ETH_QOS_QCOM=y
> +CONFIG_PHY=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCONF=y
> +CONFIG_PINCTRL_QCOM_SM8150=y
> +CONFIG_POWER_DOMAIN=y
> +CONFIG_MSM_GENI_SERIAL=y
> +CONFIG_SPMI_MSM=y
> +CONFIG_LMB_MAX_REGIONS=64
Apart from above, I think this platform should be able to reuse
qcom_defconfig as you can find most of the config options there. Can
you try to reuse it?
> diff --git a/doc/board/qualcomm/index.rst b/doc/board/qualcomm/index.rst
> index 4955274a39..268218b05f 100644
> --- a/doc/board/qualcomm/index.rst
> +++ b/doc/board/qualcomm/index.rst
> @@ -7,5 +7,6 @@ Qualcomm
>
Re: [PATCH v3] board: rockchip: add Rockchip Toybrick TB-RK3588X board
On Tue, Mar 05, 2024 at 09:29:22AM +0800, zhangzj wrote:
> +
> +#ifdef CONFIG_OF_BOARD_SETUP
> +static int rk3588_add_reserved_memory_fdt_nodes(void *new_blob)
> +{
> + struct fdt_memory gap1 = {
> + .start = 0x3fc00,
> + .end = 0x3fc4f,
> + };
> + struct fdt_memory gap2 = {
> + .start = 0x3fff0,
> + .end = 0x3,
> + };
> + unsigned long flags = FDTDEC_RESERVED_MEMORY_NO_MAP;
> + unsigned int ret;
"ret" should be int. This doesn't affect runtime at all though.
#nitpicking
regards,
dan carpenter
> +
> + /*
> + * Inject the reserved-memory nodes into the DTS
> + */
> + ret = fdtdec_add_reserved_memory(new_blob, "gap1", , NULL, 0,
> + NULL, flags);
> + if (ret)
> + return ret;
> +
> + return fdtdec_add_reserved_memory(new_blob, "gap2", , NULL, 0,
> + NULL, flags);
> +}
[PATCH v2] mtd: nand: arasan: Fix the crash caused by use after free
The below exception observed on QEMU, as it doesn't support
NAND controller.
"Synchronous Abort" handler, esr 0x9605, far 0x17acfc878
elr: 0803ad40 lr : 0805f438 (reloc)
elr: 7fcb4d40 lr : 7fcd9438
x0 : 7bbfc880 x1 : ff10
x2 : 7fcf059c x3 : 7bbfc870
x4 : 7fd9a388 x5 : 00017acfc870
x6 : x7 : 7bbfd0e0
x8 : 3dd4 x9 : 7bbeec0c
x10: 0001 x11: 3f8c
x12: 7bbeecfc x13: 7bbeeeb0
x14: 7bbeeeb0 x15: 7bbee474
x16: 7fcef18c x17:
x18: 7bbf9d70 x19: 7bbfc888
x20: 7bbfc870 x21: 7fd68ddb
x22: ffed x23: 7bbfc878
x24: x25:
x26: x27:
x28: x29: 7bbeed10
Code: 927ff8c1 924000c6 8b010065 f9400887 (f94004a2)
Resetting CPU ...
The crash is caused by the use after free.
Updating the correct return codes rather than hardcoding.
Fixes: 3dd0f8cccd6d ("mtd: nand: Remove hardcoded base address of nand")
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Updated the commit description.
---
drivers/mtd/nand/raw/arasan_nfc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
b/drivers/mtd/nand/raw/arasan_nfc.c
index 0b1b91f771..ffcd963b3d 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1232,7 +1232,7 @@ static int arasan_probe(struct udevice *dev)
struct nand_config *nand = >config;
struct mtd_info *mtd;
ofnode child;
- int err = -1;
+ int ret;
const char *str;
info->reg = dev_read_addr_ptr(dev);
@@ -1259,9 +1259,10 @@ static int arasan_probe(struct udevice *dev)
writel(0x0, >reg->pgm_reg);
/* first scan to find the device and get the page size */
- if (nand_scan_ident(mtd, CONFIG_SYS_NAND_MAX_CHIPS, NULL)) {
+ ret = nand_scan_ident(mtd, CONFIG_SYS_NAND_MAX_CHIPS, NULL);
+ if (ret) {
printf("%s: nand_scan_ident failed\n", __func__);
- goto fail;
+ return ret;
}
str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
@@ -1289,26 +1290,26 @@ static int arasan_probe(struct udevice *dev)
nand_chip->ecc.bytes = 0;
nand_chip->ecc.layout = _nand_oob_64;
} else {
- if (arasan_nand_ecc_init(mtd)) {
+ ret = arasan_nand_ecc_init(mtd);
+ if (ret) {
printf("%s: nand_ecc_init failed\n", __func__);
- goto fail;
+ return ret;
}
}
- if (nand_scan_tail(mtd)) {
+ ret = nand_scan_tail(mtd);
+ if (ret) {
printf("%s: nand_scan_tail failed\n", __func__);
- goto fail;
+ return ret;
}
- if (nand_register(0, mtd)) {
+ ret = nand_register(0, mtd);
+ if (ret) {
printf("Nand Register Fail\n");
- goto fail;
+ return ret;
}
- return 0;
-fail:
- free(nand);
- return err;
+ return ret;
}
static const struct udevice_id arasan_nand_dt_ids[] = {
--
2.17.1
[PATCH v4] mtd: nand: arasan: Print warning for unsupported ecc modes
Currently only hw ecc is supported in U-Boot. If any other ecc mode is
given in DT, it simply through an error. So better print
what is being done.
Revert this patch once soft ecc support is fixed in future.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Added the ecc mode check in the arasan driver itself.
Changes in v3:
- Skip the driver probe when sw-ecc mode is present in the device tree.
Changes in v4:
- Updated the commit description to through an error if other
than hw ecc mentioned in the DT.
- Added the NULL check.
---
drivers/mtd/nand/raw/arasan_nfc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
b/drivers/mtd/nand/raw/arasan_nfc.c
index 14766401bf..0b1b91f771 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1233,6 +1233,7 @@ static int arasan_probe(struct udevice *dev)
struct mtd_info *mtd;
ofnode child;
int err = -1;
+ const char *str;
info->reg = dev_read_addr_ptr(dev);
mtd = nand_to_mtd(nand_chip);
@@ -1263,6 +1264,12 @@ static int arasan_probe(struct udevice *dev)
goto fail;
}
+ str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
+ if (!str || strcmp(str, "hw") != 0) {
+ printf("%s ecc mode is not supported\n", str);
+ return -EINVAL;
+ }
+
nand_chip->ecc.mode = NAND_ECC_HW;
nand_chip->ecc.hwctl = NULL;
nand_chip->ecc.read_page = arasan_nand_read_page_hwecc;
--
2.17.1
[PATCH] riscv: dts: jh7110: Enable PLL node in SPL
Previously PLL node was missing from SPL dts. This caused BUS_ROOT
to stay on OSC clock (24Mhz). As a result, all peripherals have to
run at a much lower frequency, and loading from sdcard/emmc is slow.
Thus, enabling PLL node in dts to fix this.
Signed-off-by: Bo Gan
---
arch/riscv/dts/jh7110-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi
b/arch/riscv/dts/jh7110-u-boot.dtsi
index 2f560e7..c09d5c9 100644
--- a/arch/riscv/dts/jh7110-u-boot.dtsi
+++ b/arch/riscv/dts/jh7110-u-boot.dtsi
@@ -93,6 +93,10 @@
bootph-pre-ram;
};
+ {
+ bootph-pre-ram;
+};
+
_0 {
status = "okay";
};
--
2.7.4
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On 3/5/24 10:41 PM, Michael Walle wrote:
On Tue Mar 5, 2024 at 7:54 PM CET, Marek Vasut wrote:
On 3/5/24 5:55 PM, Michael Walle wrote:
[...]
Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
Linux, since Linux that is booted afterward then gets a device that has
locking scheme configured in a way that Linux expects and can operate.
Better yet, if some old LTS version of the Linux kernel is in use, it
will also work correctly, because this patch will configure the SPI NOR
locking scheme to what Linux expects it to be, before the SPI NOR is
handed over to that old kernel.
Agreed, but it should *not* be done automatically and nor
unconditionally. Please don't just overwrite any locking bits just
because there is one flash which have it set.
The unlock code is not triggered unconditionally, it is protected by
if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
Kconfig option, so this can be turned on/off in board config already.
Ahh, OK then :)
But keep in mind that enabling this option is foobar and I've gone
lengths to eliminate it in linux. And actually made that option in
u-boot.
See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
are non-volatile").
So, how shall we proceed here?
Regarding this patch, I think it's fine. It will unlock the whole
flash as advertised.
This change won't unlock the flash, it will switch to the supported
locking scheme, one which can then be used to unlock the flash.
I can't follow you here. The code is added right below the
write_sr(0), which will clear all the BP bits, thus unlocking
everything if WPS=0. Therefore, no locking will be enabled anymore
afterwards. What did I miss?
Ah, I think you didn't miss anything. Toggling the SR3 WPS does not
clear any lock bits (BP or page ones), it only selects the locking
scheme. The SR0 write does clear lock bits (BP ones) using the standard
locking scheme.
But u-boot should really consider making that a "default n" option.
And most likely adding =y to every existing defconfig out there so
that at least new boards will benefit from it.
Yes, I agree with that.
The way I see this, if Linux ever implements this scheme, Linux can set
the SR3 WPS bit as needed, it does not matter which way bootloader sets
the bit as the protection bits are not cleared when the bit is cleared,
they seem to be stored elsewhere.
On each reboot you'd wear out that cell with two erases/writes.
That's another reason why that whole unlocking thing is foobar for
non-volatile bits. For me, non-volatile bits are for provisioning,
so during a normal boot they should not be touched at all. Just
during board manufacturing or because the user actively want to
protect something.
That is what happens here, the write to clear the bit is triggered only
if the bit is set , so OK .
And if Linux wants to use the new locking scheme, then the bootloader
should ideally be updated to match, i.e. SPI_FLASH_UNLOCK_ALL=n etc, so
that is also OK .
I'd argue if one wants to use the locking at all, you have to set
UNLOCK_ALL=n. Otherwise, the bootloader might come alone and just
clear your locking bits again. Clearing the WPS bit there is just
one more thing which IMHO doesn't make much sense.
On the other hand, if UNLOCK_ALL=y is supposed to work and reset
locking, then the SR3 WPS bit has to be configured to select the
standard SPI NOR locking scheme, so the locking can actually be reset
using that scheme.
In other words, there should be no writes into the non-volatile bits,
unless U-Boot and Linux disagree on the locking scheme,
Agreed.
in which case
writes are unavoidable (if you want unlock to work in both projects).
But this should only happen if the user want to change the locking
at all. u-boot should not just do "oh this bit is set, I'm clearing
it" during SPI flash probe. Again, I'm not caring much if this is
guarded by the UNLOCK_ALL=y, because u-boot is already doing "oh the
BP bits are set, lets clear em".
It is guarded, yes.
If you clear this bit during the unlock all command, all the locking
bits are cleared anyway. Or do you mean, the individual bits are
still retained?
The lock bits themselves are retained, this SR3 WPS only selects which
of those bits take effect, whether the SR ones (standard locking scheme)
or the per-page ones (winbond custom locking scheme).
Ok. So switching back to WPS=1 might come with some suprises :)
Yes, the bad kind.
[PATCH v2 0/8] Add support for Qualcomm SA8155-ADP board
This patch series adds support for Qualcomm SA8155-ADP development board. Main motivation for this series is to allow running virtualization software on this board and U-Boot is a good way to break Qualcomm's boot chain at EL2 with more convenient ways for uploading and running the code. With this patches applied it is possible to upload and run Xen on this board. KVM probably should work too. I added myself as a maintainer for this board, but my abilities to maintain it are quite limited as I have no access to Qualcomm documentation. I used mostly Linux drivers as the source for device-specific information, like register addresses and offsets. If anyone wants to maintain this, I will gladly agree. This is the second version of the series. It is now rebased onto qcom-next branch. Changes in v2: - New patch in v2 - Clear loopback bit explicitly - Reworked qcom_cc_bind() function - Added timeout to qcom_power_set() - Minor fixes in register names and formatting - Renamed GPLL7_MAIN to just GPLL7 (while I like idea to use Linux naming convention, such rework needs to be done in a separate commit) - Removed unnecessary include - Fixed GDSCR register values for couple of devices - Enable GPLL7 only when RGMII clock is enabled - Rebased onto qcom-next branch - Removed unnecessary files thanks to generic qualcomm board support - Enabled CONFIG_REMAKE_ELF (this removes one extra step in the readme) Volodymyr Babchuk (8): qcom: board: validate fdt before trying to use it clk: qcom: clear div mask before assigning a new divider net: dw_eth_qos: add support for Qualcomm SM8150 SoC clk: qcom: add support for power domains uclass clk: qcom: add driver for SM8150 SoC pinctrl: qcom: pass pin number to get_function_mux callback pinctrl: qcom: add driver for SM8150 SoC board: add support for Qualcomm SA8155P-ADP board arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 ++ arch/arm/mach-snapdragon/board.c | 5 +- board/qualcomm/sa8155p-adp/MAINTAINERS | 5 + configs/sa8155p_adp_defconfig | 35 ++ doc/board/qualcomm/index.rst | 1 + doc/board/qualcomm/sa8155p-adp.rst | 87 drivers/clk/qcom/Kconfig | 8 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clock-qcom.c | 131 +- drivers/clk/qcom/clock-qcom.h | 7 + drivers/clk/qcom/clock-sm8150.c| 237 ++ drivers/net/dwc_eth_qos.c | 4 + drivers/net/dwc_eth_qos.h | 2 + drivers/net/dwc_eth_qos_qcom.c | 46 +- drivers/pinctrl/qcom/Kconfig | 7 + drivers/pinctrl/qcom/Makefile | 1 + drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 +- drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 +- drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 +- drivers/pinctrl/qcom/pinctrl-qcom.c| 4 +- drivers/pinctrl/qcom/pinctrl-qcom.h| 3 +- drivers/pinctrl/qcom/pinctrl-qcs404.c | 3 +- drivers/pinctrl/qcom/pinctrl-sdm845.c | 3 +- drivers/pinctrl/qcom/pinctrl-sm8150.c | 589 + 24 files changed, 1186 insertions(+), 32 deletions(-) create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS create mode 100644 configs/sa8155p_adp_defconfig create mode 100644 doc/board/qualcomm/sa8155p-adp.rst create mode 100644 drivers/clk/qcom/clock-sm8150.c create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c -- 2.43.0
[PATCH v2 3/8] net: dw_eth_qos: add support for Qualcomm SM8150 SoC
Add support for Qualcomm SM8150 SoC to the EQOS driver. SM8150 has two
main differences from already supported QCS404: it has another RGMII
configuration registers set and it does require RGMII loopback to
be disabled.
To support different variants of QCOM SoC we had to add two new fields
to the eqos_priv struct: eqos_qcom_rgmii_regs and
qcom_enable_loopback.
Signed-off-by: Volodymyr Babchuk
---
Changes in v2:
- Clear loopback bit explicitly
drivers/net/dwc_eth_qos.c | 4 +++
drivers/net/dwc_eth_qos.h | 2 ++
drivers/net/dwc_eth_qos_qcom.c | 46 +++---
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 9b3bce1dc8..882b854697 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1700,6 +1700,10 @@ static const struct udevice_id eqos_ids[] = {
.compatible = "qcom,qcs404-ethqos",
.data = (ulong)_qcom_config
},
+ {
+ .compatible = "qcom,sm8150-ethqos",
+ .data = (ulong)_qcom_config
+ },
#endif
#if IS_ENABLED(CONFIG_DWC_ETH_QOS_STARFIVE)
{
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index e3222e1e17..216e1afe53 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -255,6 +255,7 @@ struct eqos_priv {
struct eqos_dma_regs *dma_regs;
struct eqos_tegra186_regs *tegra186_regs;
void *eqos_qcom_rgmii_regs;
+ struct dwmac_rgmii_regs *eqos_qcom_por;
struct reset_ctl reset_ctl;
struct gpio_desc phy_reset_gpio;
struct clk clk_master_bus;
@@ -277,6 +278,7 @@ struct eqos_priv {
bool started;
bool reg_access_ok;
bool clk_ck_enabled;
+ bool qcom_enable_loopback;
unsigned int tx_fifo_sz, rx_fifo_sz;
u32 reset_delays[3];
};
diff --git a/drivers/net/dwc_eth_qos_qcom.c b/drivers/net/dwc_eth_qos_qcom.c
index 8178138fc6..ee8420c71d 100644
--- a/drivers/net/dwc_eth_qos_qcom.c
+++ b/drivers/net/dwc_eth_qos_qcom.c
@@ -95,6 +95,15 @@ static struct dwmac_rgmii_regs emac_v2_3_0_por = {
.io_macro_config2 = 0x2060
};
+static struct dwmac_rgmii_regs emac_v2_1_0_por = {
+ .io_macro_config = 0x40C01343,
+ .sdcc_hc_dll_config = 0x2004642C,
+ .sdcc_hc_ddr_config = 0x,
+ .sdcc_hc_dll_config2 = 0x0020,
+ .sdcc_usr_ctl = 0x00010800,
+ .io_macro_config2 = 0x2060
+};
+
static void ethqos_set_func_clk_en(struct dwmac_rgmii_regs *regs)
{
setbits_le32(>io_macro_config, RGMII_CONFIG_FUNC_CLK_EN);
@@ -172,6 +181,10 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
struct dwmac_rgmii_regs *regs,
unsigned long speed)
{
+ struct eqos_priv *eqos = dev_get_priv(dev);
+ uint32_t loopback =
+ eqos->qcom_enable_loopback ? RGMII_CONFIG_LOOPBACK_EN : 0;
+
/* Disable loopback mode */
clrbits_le32(>io_macro_config2,
RGMII_CONFIG2_TX_TO_RX_LOOPBACK_EN);
@@ -202,7 +215,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
SDCC_DDR_CONFIG_PRG_RCLK_DLY, 57);
setbits_le32(>sdcc_hc_ddr_config,
SDCC_DDR_CONFIG_PRG_DLY_EN);
- setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+ clrsetbits_le32(>io_macro_config,
+ RGMII_CONFIG_LOOPBACK_EN, loopback);
break;
case SPEED_100:
@@ -233,7 +247,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
setbits_le32(>sdcc_hc_ddr_config,
SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
- setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+ clrsetbits_le32(>io_macro_config,
+ RGMII_CONFIG_LOOPBACK_EN, loopback);
break;
case SPEED_10:
@@ -265,7 +280,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
setbits_le32(>sdcc_hc_ddr_config,
SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
- setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+ clrsetbits_le32(>io_macro_config,
+ RGMII_CONFIG_LOOPBACK_EN, loopback);
break;
default:
@@ -281,14 +297,15 @@ static int ethqos_configure(struct udevice *dev,
unsigned long speed)
{
unsigned int retry = 1000;
+ struct eqos_priv *eqos = dev_get_priv(dev);
/* Reset to POR values and enable clk */
- writel(emac_v2_3_0_por.io_macro_config, >io_macro_config);
- writel(emac_v2_3_0_por.sdcc_hc_dll_config, >sdcc_hc_dll_config);
- writel(emac_v2_3_0_por.sdcc_hc_ddr_config, >sdcc_hc_ddr_config);
- writel(emac_v2_3_0_por.sdcc_hc_dll_config2,
[PATCH v2 6/8] pinctrl: qcom: pass pin number to get_function_mux callback
This patch is the preparation for SM8150 support. This new SoC
depending on the particular pin can have different numbers for the
same function. For example "rgmii" function for GPIO4 has id=2 while
for GPIO59 it has id=1. So, to support this type of SoCs,
get_function_mux() callback needs to know for which pin the function
is requested.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Caleb Connolly
---
Changes in v2:
- Added Caleb's R-b tag
drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 ++-
drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 ++-
drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 ++-
drivers/pinctrl/qcom/pinctrl-qcom.c| 4 ++--
drivers/pinctrl/qcom/pinctrl-qcom.h| 3 ++-
drivers/pinctrl/qcom/pinctrl-qcs404.c | 3 ++-
drivers/pinctrl/qcom/pinctrl-sdm845.c | 3 ++-
7 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index db0e212468..a9a00f4b08 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -49,7 +49,8 @@ static const char *apq8016_get_pin_name(struct udevice *dev,
}
}
-static unsigned int apq8016_get_function_mux(unsigned int selector)
+static unsigned int apq8016_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
{
return msm_pinctrl_functions[selector].val;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8096.c
b/drivers/pinctrl/qcom/pinctrl-apq8096.c
index 880df8fe3c..9697cb5beb 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8096.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8096.c
@@ -44,7 +44,8 @@ static const char *apq8096_get_pin_name(struct udevice *dev,
}
}
-static unsigned int apq8096_get_function_mux(unsigned int selector)
+static unsigned int apq8096_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
{
return msm_pinctrl_functions[selector].val;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
index 74c04ab87c..4479230313 100644
--- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
@@ -40,7 +40,8 @@ static const char *ipq4019_get_pin_name(struct udevice *dev,
return pin_name;
}
-static unsigned int ipq4019_get_function_mux(unsigned int selector)
+static unsigned int ipq4019_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
{
return msm_pinctrl_functions[selector].val;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index ee0624df29..909e566acf 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -83,14 +83,14 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int
pin_selector,
unsigned int func_selector)
{
struct msm_pinctrl_priv *priv = dev_get_priv(dev);
+ u32 func = priv->data->get_function_mux(pin_selector, func_selector);
/* Always NOP for special pins, assume they're in the correct state */
if (qcom_is_special_pin(>data->pin_data, pin_selector))
return 0;
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
- TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE,
- priv->data->get_function_mux(func_selector) << 2);
+ TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
return 0;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.h
b/drivers/pinctrl/qcom/pinctrl-qcom.h
index 07f2eae9ba..49b7bfbc00 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.h
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.h
@@ -18,7 +18,8 @@ struct msm_pinctrl_data {
int functions_count;
const char *(*get_function_name)(struct udevice *dev,
unsigned int selector);
- unsigned int (*get_function_mux)(unsigned int selector);
+ unsigned int (*get_function_mux)(unsigned int pin,
+unsigned int selector);
const char *(*get_pin_name)(struct udevice *dev,
unsigned int selector);
};
diff --git a/drivers/pinctrl/qcom/pinctrl-qcs404.c
b/drivers/pinctrl/qcom/pinctrl-qcs404.c
index 3a2d468599..4b7c670c90 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcs404.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcs404.c
@@ -94,7 +94,8 @@ static const char *qcs404_get_pin_name(struct udevice *dev,
}
}
-static unsigned int qcs404_get_function_mux(unsigned int selector)
+static unsigned int qcs404_get_function_mux(__maybe_unused unsigned int pin,
+ unsigned int selector)
{
return msm_pinctrl_functions[selector].val;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index
[PATCH v2 8/8] board: add support for Qualcomm SA8155P-ADP board
SA8155P Automotive Development Platform is Qualcomm SA8155-based board
for developers. The nice thing that it has unlocked loaders with test
keys support, which means that U-Boot for this platform can be
launched at earlier stages.
This patch adds basic board support with only serial port and
networking operation. I am using U-Boot to ease up Xen porting onto
this board, so I am mostly interesting in booting U-Boot in EL2. But
more conventional setup with Android boot image is supported as well.
Signed-off-by: Volodymyr Babchuk
---
Changes in v2:
- Rebased onto qcom-next branch
- Removed unnecessary files thanks to generic qualcomm board support
- Enabled CONFIG_REMAKE_ELF (this removes one extra step in the
readme)
arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 +
board/qualcomm/sa8155p-adp/MAINTAINERS | 5 ++
configs/sa8155p_adp_defconfig | 35 +++
doc/board/qualcomm/index.rst | 1 +
doc/board/qualcomm/sa8155p-adp.rst | 87 ++
5 files changed, 158 insertions(+)
create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
create mode 100644 configs/sa8155p_adp_defconfig
create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
diff --git a/arch/arm/dts/sa8155p-adp-u-boot.dtsi
b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
new file mode 100644
index 00..ffbf0933c7
--- /dev/null
+++ b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Qualcomm SA8155P-ADP device tree fixups for U-BOot
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2024 EPAM Systems.
+ */
+
+/ {
+ /* Populate memory node with actual memory configuration */
+ memory@8000 {
+ reg = <0x00 0x8000 0x00 0x3990>,
+ <0x02 0x00x1 0x7fd0>,
+ <0x00 0xC000 0x1 0x4000>;
+ };
+};
+
+ {
+ /* Ethernet driver tries to find reset by name */
+ reset-names = "emac";
+};
+
+ {
+ /* U-Boot pinctrl driver does not understand multiple tiles */
+ reg = <0x0 0x0300 0x0 0x100>;
+ /delete-property/ reg-names;
+
+ /* U-Boot ethernet driver wants to drive reset as GPIO */
+ /delete-node/ phy-reset-pins;
+};
diff --git a/board/qualcomm/sa8155p-adp/MAINTAINERS
b/board/qualcomm/sa8155p-adp/MAINTAINERS
new file mode 100644
index 00..03fac84f51
--- /dev/null
+++ b/board/qualcomm/sa8155p-adp/MAINTAINERS
@@ -0,0 +1,5 @@
+Qualcomm SA8155P Automotive Development Platform
+M: Volodymyr Babchuk
+S: Maintained
+F: board/qualcomm/sa8155p-adp/
+F: configs/sa8155p-adp_defconfig
diff --git a/configs/sa8155p_adp_defconfig b/configs/sa8155p_adp_defconfig
new file mode 100644
index 00..b6969767f8
--- /dev/null
+++ b/configs/sa8155p_adp_defconfig
@@ -0,0 +1,35 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=1900
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
+CONFIG_ARCH_SNAPDRAGON=y
+CONFIG_TEXT_BASE=0x8571
+CONFIG_DEFAULT_DEVICE_TREE="qcom/sa8155p-adp"
+CONFIG_IDENT_STRING="\nQualcomm SA8155P-ADP"
+CONFIG_SYS_LOAD_ADDR=0x8571
+CONFIG_REMAKE_ELF=y
+CONFIG_BOOTDELAY=3
+CONFIG_SYS_CBSIZE=512
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_OF_UPSTREAM=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_CLK=y
+CONFIG_CLK_QCOM_SM8150=y
+CONFIG_MSM_GPIO=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_ETH_PHY=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_QCOM=y
+CONFIG_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_QCOM_SM8150=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MSM_GENI_SERIAL=y
+CONFIG_SPMI_MSM=y
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/doc/board/qualcomm/index.rst b/doc/board/qualcomm/index.rst
index 4955274a39..268218b05f 100644
--- a/doc/board/qualcomm/index.rst
+++ b/doc/board/qualcomm/index.rst
@@ -7,5 +7,6 @@ Qualcomm
:maxdepth: 2
dragonboard410c
+ sa8155p-adp
board
debugging
diff --git a/doc/board/qualcomm/sa8155p-adp.rst
b/doc/board/qualcomm/sa8155p-adp.rst
new file mode 100644
index 00..66db512b52
--- /dev/null
+++ b/doc/board/qualcomm/sa8155p-adp.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. sectionauthor:: Volodymyr Babchuk
+
+SA8155P Automotive Development Platform
+===
+
+About
+-
+This document describes the information about SA8155P Automotive
+Development Platform aka SA8155P-ADP.
+
+Currently U-Boot can be booted either as Android boot image, or in EL2
+mode, instead of hypervisor image. In the latter case it is possible
+to use U-Boot to either boot Linux with KVM support or to boot Xen
+Hypervisor on this board.
+
+Supported HW modules
+
+Port for this board is in early development state. Right now U-Boot
+supports serial console and networking. No USB/fastboot or UFS support
+yet. So
[PATCH v2 5/8] clk: qcom: add driver for SM8150 SoC
Add clock, reset and power domain driver for SM8150. Driver code is
based on the similar U-Boot drivers. All constants are taken from the
corresponding Linux driver.
This driver supports clock rate setting only for the debug UART and
RGMII/Ethernet modules, because this is all I can test right now.
Signed-off-by: Volodymyr Babchuk
---
Changes in v2:
- Renamed GPLL7_MAIN to just GPLL7 (while I like idea to use Linux
naming convention, such rework needs to be done in a separate
commit)
- Removed unnecessary include
- Fixed GDSCR register values for couple of devices
- Enable GPLL7 only when RGMII clock is enabled
drivers/clk/qcom/Kconfig| 8 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clock-qcom.h | 1 +
drivers/clk/qcom/clock-sm8150.c | 237
4 files changed, 247 insertions(+)
create mode 100644 drivers/clk/qcom/clock-sm8150.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0df0d1881a..18ccf6a45e 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
on the Snapdragon 845 SoC. This driver supports the clocks
and resets exposed by the GCC hardware block.
+config CLK_QCOM_SM8150
+ bool "Qualcomm SM8150 GCC"
+ select CLK_QCOM
+ help
+ Say Y here to enable support for the Global Clock Controller
+ on the Snapdragon 8150 SoC. This driver supports the clocks
+ and resets exposed by the GCC hardware block.
+
endmenu
endif
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index cb179fdac5..12c09ba19e 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
+obj-$(CONFIG_CLK_QCOM_SM8150) += clock-sm8150.o
diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
index 12a1eaec2b..dd40487e94 100644
--- a/drivers/clk/qcom/clock-qcom.h
+++ b/drivers/clk/qcom/clock-qcom.h
@@ -9,6 +9,7 @@
#define CFG_CLK_SRC_CXO (0 << 8)
#define CFG_CLK_SRC_GPLL0 (1 << 8)
+#define CFG_CLK_SRC_GPLL7 (3 << 8)
#define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
#define CFG_CLK_SRC_MASK (7 << 8)
diff --git a/drivers/clk/qcom/clock-sm8150.c b/drivers/clk/qcom/clock-sm8150.c
new file mode 100644
index 00..2592eef29b
--- /dev/null
+++ b/drivers/clk/qcom/clock-sm8150.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Clock drivers for Qualcomm SM8150
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2024 EPAM Systems.
+ *
+ * Based on U-Boot driver for SDM845. Constants are taken from the Linux
driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clock-qcom.h"
+
+static struct pll_vote_clk gpll7_vote_clk = {
+ .status = 0x1a000,
+ .status_bit = BIT(31),
+ .ena_vote = 0x52000,
+ .vote_bit = BIT(7),
+};
+
+static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
+ F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
+ F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
+ F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+ F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
+ F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
+ F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
+ F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
+ F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
+ F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
+ F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
+ F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
+ F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
+ F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
+ F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
+ F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
+ { }
+};
+
+static const struct freq_tbl ftbl_gcc_emac_rgmii_clk_src[] = {
+ F(250, CFG_CLK_SRC_CXO, 1, 25, 192),
+ F(500, CFG_CLK_SRC_CXO, 1, 25, 96),
+ F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+ F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
+ F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
+ F(12500, CFG_CLK_SRC_GPLL7, 4, 0, 0),
+ F(25000, CFG_CLK_SRC_GPLL7, 2, 0, 0),
+ { }
+};
+
+static const struct bcr_regs uart2_regs = {
+ .cfg_rcgr = 0x1814C,
+ .cmd_rcgr = 0x18148,
+ .M = 0x18150,
+ .N = 0x18154,
+ .D = 0x18158,
+};
+
+static const struct bcr_regs rgmii_regs = {
+ .cfg_rcgr = 0x6020,
+ .cmd_rcgr = 0x601C,
+ .M = 0x6024,
+ .N = 0x6028,
+ .D = 0x602C,
+};
+
+static ulong sm8150_clk_set_rate(struct clk *clk, ulong rate)
+{
+ struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+ const struct freq_tbl *freq;
+
+ switch (clk->id) {
+
[PATCH v2 4/8] clk: qcom: add support for power domains uclass
Now sub-drivers for particular SoCs can register them as power domain
drivers. This is needed for upcoming SM8150 support, because it needs
to power up the Ethernet module.
Signed-off-by: Volodymyr Babchuk
---
Changes in v2:
- Reworked qcom_cc_bind() function
- Added timeout to qcom_power_set()
- Minor fixes in register names and formatting
drivers/clk/qcom/clock-qcom.c | 128 ++
drivers/clk/qcom/clock-qcom.h | 6 ++
2 files changed, 121 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
index 729d190c54..c3f8d96183 100644
--- a/drivers/clk/qcom/clock-qcom.c
+++ b/drivers/clk/qcom/clock-qcom.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "clock-qcom.h"
@@ -30,6 +31,13 @@
#define CBCR_BRANCH_ENABLE_BIT BIT(0)
#define CBCR_BRANCH_OFF_BIT BIT(31)
+#define GDSC_SW_COLLAPSE_MASK BIT(0)
+#define GDSC_POWER_DOWN_COMPLETE BIT(15)
+#define GDSC_POWER_UP_COMPLETE BIT(16)
+#define GDSC_PWR_ON_MASK BIT(31)
+#define CFG_GDSCR_OFFSET 0x4
+#define GDSC_STATUS_POLL_TIMEOUT_US1500
+
/* Enable clock controlled by CBC soft macro */
void clk_enable_cbc(phys_addr_t cbcr)
{
@@ -223,7 +231,7 @@ U_BOOT_DRIVER(qcom_clk) = {
int qcom_cc_bind(struct udevice *parent)
{
struct msm_clk_data *data = (struct msm_clk_data
*)dev_get_driver_data(parent);
- struct udevice *clkdev, *rstdev;
+ struct udevice *clkdev = NULL, *rstdev = NULL, *pwrdev;
struct driver *drv;
int ret;
@@ -238,20 +246,41 @@ int qcom_cc_bind(struct udevice *parent)
if (ret)
return ret;
- /* Bail out early if resets are not specified for this platform */
- if (!data->resets)
- return ret;
+ if (data->resets) {
+ /* Get a handle to the common reset handler */
+ drv = lists_driver_lookup_name("qcom_reset");
+ if (!drv) {
+ ret = -ENOENT;
+ goto unbind_clkdev;
+ }
+
+ /* Register the reset controller */
+ ret = device_bind_with_driver_data(parent, drv, "qcom_reset",
(ulong)data,
+ dev_ofnode(parent), );
+ if (ret)
+ goto unbind_clkdev;
+ }
- /* Get a handle to the common reset handler */
- drv = lists_driver_lookup_name("qcom_reset");
- if (!drv)
- return -ENOENT;
+ if (data->power_domains) {
+ /* Get a handle to the common power domain handler */
+ drv = lists_driver_lookup_name("qcom_power");
+ if (!drv) {
+ ret = -ENOENT;
+ goto unbind_rstdev;
+ }
+ /* Register the power domain controller */
+ ret = device_bind_with_driver_data(parent, drv, "qcom_power",
(ulong)data,
+ dev_ofnode(parent), );
+ if (ret)
+ goto unbind_rstdev;
+ }
- /* Register the reset controller */
- ret = device_bind_with_driver_data(parent, drv, "qcom_reset",
(ulong)data,
- dev_ofnode(parent), );
- if (ret)
- device_unbind(clkdev);
+ return 0;
+
+unbind_rstdev:
+ device_unbind(rstdev);
+unbind_clkdev:
+ device_unbind(clkdev);
return ret;
}
@@ -306,3 +335,76 @@ U_BOOT_DRIVER(qcom_reset) = {
.ops = _reset_ops,
.probe = qcom_reset_probe,
};
+
+static int qcom_power_set(struct power_domain *pwr, bool on)
+{
+ struct msm_clk_data *data = (struct msm_clk_data
*)dev_get_driver_data(pwr->dev);
+ void __iomem *base = dev_get_priv(pwr->dev);
+ unsigned long timeout;
+ const struct qcom_power_map *map;
+ u32 value;
+
+ if (pwr->id >= data->num_power_domains)
+ return -ENODEV;
+
+ map = >power_domains[pwr->id];
+
+ if (!map->reg)
+ return -ENODEV;
+
+ value = readl(base + map->reg);
+
+ if (on)
+ value &= ~GDSC_SW_COLLAPSE_MASK;
+ else
+ value |= GDSC_SW_COLLAPSE_MASK;
+
+ writel(value, base + map->reg);
+
+ timeout = timer_get_us() + GDSC_STATUS_POLL_TIMEOUT_US;
+ /* Wait for power on */
+ while (timeout > timer_get_us()) {
+ value = readl(base + map->reg + CFG_GDSCR_OFFSET);
+ if (on) {
+ if ((value & GDSC_POWER_UP_COMPLETE) ||
+ (value & GDSC_PWR_ON_MASK))
+ return 0;
+ } else {
+ if (value & GDSC_POWER_DOWN_COMPLETE ||
+ !(value & GDSC_PWR_ON_MASK))
+ return 0;
+ }
+ }
+
[PATCH v2 2/8] clk: qcom: clear div mask before assigning a new divider
The current behaviour does a bitwise OR of the previous and new divider values, this is wrong as some bits maybe be set already. We need to clear all the divider bits before applying new ones. This fixes potential issue with 1Gbit ethernet on SA8155P-ADP boards. Signed-off-by: Volodymyr Babchuk Reviewed-by: Caleb Connolly --- Changes in v2: - Reworded the commit message - Added Caleb's R-b tag drivers/clk/qcom/clock-qcom.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c index 7c683e5192..729d190c54 100644 --- a/drivers/clk/qcom/clock-qcom.c +++ b/drivers/clk/qcom/clock-qcom.c @@ -117,7 +117,8 @@ void clk_rcg_set_rate_mnd(phys_addr_t base, const struct bcr_regs *regs, /* setup src select and divider */ cfg = readl(base + regs->cfg_rcgr); - cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK); + cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK | +CFG_SRC_DIV_MASK); cfg |= source & CFG_SRC_SEL_MASK; /* Select clock source */ if (div) -- 2.43.0
[PATCH v2 7/8] pinctrl: qcom: add driver for SM8150 SoC
Add pinctrl and GPIO driver for SM8150. Driver code is based on the
similar U-Boot drivers. All constants are taken from the corresponding
Linux driver. This drivers differs from the similar U-Boot drivers,
because SM8150 SoC have different function IDs for the same functions
on different pins.
Signed-off-by: Volodymyr Babchuk
---
(no changes since v1)
drivers/pinctrl/qcom/Kconfig | 7 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-sm8150.c | 589 ++
3 files changed, 597 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 2fe6398147..290cefca47 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -41,6 +41,13 @@ config PINCTRL_QCOM_SDM845
Say Y here to enable support for pinctrl on the Snapdragon 845 SoC,
as well as the associated GPIO driver.
+config PINCTRL_QCOM_SM8150
+ bool "Qualcomm SM8150 GCC"
+ select PINCTRL_QCOM
+ help
+ Say Y here to enable support for pinctrl on the Snapdragon SM8150 SoC,
+ as well as the associated GPIO driver.
+
endmenu
endif
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 6d9aca6d7b..3c7be4a685 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_QCOM_IPQ4019) += pinctrl-ipq4019.o
obj-$(CONFIG_PINCTRL_QCOM_APQ8096) += pinctrl-apq8096.o
obj-$(CONFIG_PINCTRL_QCOM_QCS404) += pinctrl-qcs404.o
obj-$(CONFIG_PINCTRL_QCOM_SDM845) += pinctrl-sdm845.o
+obj-$(CONFIG_PINCTRL_QCOM_SM8150) += pinctrl-sm8150.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8150.c
b/drivers/pinctrl/qcom/pinctrl-sm8150.c
new file mode 100644
index 00..a6c14d7254
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sm8150.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Qualcomm SM8150 pinctrl and GPIO driver
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2024 EPAM Systems.
+ *
+ * Based on similar U-Boot drivers. Constants were taken from the Linux driver
+ */
+
+#include
+
+#include "pinctrl-qcom.h"
+
+#define WEST 0x0010
+#define EAST 0x0050
+#define NORTH 0x0090
+#define SOUTH 0x00D0
+
+#define MAX_PIN_NAME_LEN 32
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
+
+enum sm8150_functions {
+ msm_mux_adsp_ext,
+ msm_mux_agera_pll,
+ msm_mux_aoss_cti,
+ msm_mux_atest_char,
+ msm_mux_atest_char0,
+ msm_mux_atest_char1,
+ msm_mux_atest_char2,
+ msm_mux_atest_char3,
+ msm_mux_atest_usb1,
+ msm_mux_atest_usb2,
+ msm_mux_atest_usb10,
+ msm_mux_atest_usb11,
+ msm_mux_atest_usb12,
+ msm_mux_atest_usb13,
+ msm_mux_atest_usb20,
+ msm_mux_atest_usb21,
+ msm_mux_atest_usb22,
+ msm_mux_atest_usb23,
+ msm_mux_audio_ref,
+ msm_mux_btfm_slimbus,
+ msm_mux_cam_mclk,
+ msm_mux_cci_async,
+ msm_mux_cci_i2c,
+ msm_mux_cci_timer0,
+ msm_mux_cci_timer1,
+ msm_mux_cci_timer2,
+ msm_mux_cci_timer3,
+ msm_mux_cci_timer4,
+ msm_mux_cri_trng,
+ msm_mux_cri_trng0,
+ msm_mux_cri_trng1,
+ msm_mux_dbg_out,
+ msm_mux_ddr_bist,
+ msm_mux_ddr_pxi0,
+ msm_mux_ddr_pxi1,
+ msm_mux_ddr_pxi2,
+ msm_mux_ddr_pxi3,
+ msm_mux_edp_hot,
+ msm_mux_edp_lcd,
+ msm_mux_emac_phy,
+ msm_mux_emac_pps,
+ msm_mux_gcc_gp1,
+ msm_mux_gcc_gp2,
+ msm_mux_gcc_gp3,
+ msm_mux_gpio,
+ msm_mux_jitter_bist,
+ msm_mux_hs1_mi2s,
+ msm_mux_hs2_mi2s,
+ msm_mux_hs3_mi2s,
+ msm_mux_lpass_slimbus,
+ msm_mux_mdp_vsync,
+ msm_mux_mdp_vsync0,
+ msm_mux_mdp_vsync1,
+ msm_mux_mdp_vsync2,
+ msm_mux_mdp_vsync3,
+ msm_mux_mss_lte,
+ msm_mux_m_voc,
+ msm_mux_nav_pps,
+ msm_mux_pa_indicator,
+ msm_mux_pci_e0,
+ msm_mux_pci_e1,
+ msm_mux_phase_flag,
+ msm_mux_pll_bist,
+ msm_mux_pll_bypassnl,
+ msm_mux_pll_reset,
+ msm_mux_pri_mi2s,
+ msm_mux_pri_mi2s_ws,
+ msm_mux_prng_rosc,
+ msm_mux_qdss,
+ msm_mux_qdss_cti,
+ msm_mux_qlink_enable,
+ msm_mux_qlink_request,
+ msm_mux_qspi0,
+ msm_mux_qspi1,
+ msm_mux_qspi2,
+ msm_mux_qspi3,
+ msm_mux_qspi_clk,
+ msm_mux_qspi_cs,
+ msm_mux_qua_mi2s,
+ msm_mux_qup0,
+ msm_mux_qup1,
+ msm_mux_qup2,
+ msm_mux_qup3,
+ msm_mux_qup4,
+ msm_mux_qup5,
+ msm_mux_qup6,
+ msm_mux_qup7,
+ msm_mux_qup8,
+ msm_mux_qup9,
+ msm_mux_qup10,
+ msm_mux_qup11,
+ msm_mux_qup12,
+ msm_mux_qup13,
+ msm_mux_qup14,
+ msm_mux_qup15,
+ msm_mux_qup16,
+ msm_mux_qup17,
+ msm_mux_qup18,
+
[PATCH v2 1/8] qcom: board: validate fdt before trying to use it
There are cases when previous bootloader stage leaves some seemingly
valid value in r0, which in fact does not point to valid FDT
blob. This behavior was encountered when trying to boot U-Boot as
"hyp" loader on SA8155P-ADP.
To be sure that we really got the pointer to a device tree we need to
validate it with fdt_valid() function.
Note: This approach is not 100% fool-proof, as get_prev_bl_fdt_addr()
theoretically can return a pointer to a region that is not physically
mapped and we will get data abort exception when "fdt_valid" will try
to access it. But at this early boot stage we don't know where RAM is
anyways so there is little we can do.
Signed-off-by: Volodymyr Babchuk
---
Changes in v2:
- New patch in v2
arch/arm/mach-snapdragon/board.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index f12f5791a1..10eec47ada 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -93,7 +94,9 @@ void *board_fdt_blob_setup(int *err)
* try and use the FDT built into U-Boot if there is one...
* This avoids having a hard dependency on the previous stage bootloader
*/
- if (IS_ENABLED(CONFIG_OF_SEPARATE) && (!fdt || fdt != ALIGN(fdt,
SZ_4K))) {
+
+ if (IS_ENABLED(CONFIG_OF_SEPARATE) && (!fdt || fdt != ALIGN(fdt, SZ_4K)
||
+ !fdt_valid((void * {
debug("%s: Using built in FDT, bootloader gave us %#llx\n",
__func__, fdt);
return (void *)gd->fdt_blob;
}
--
2.43.0
Re: [PATCH v2 5/8] phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
On Tue, Mar 5, 2024 at 7:51 AM Adam Ford wrote:
>
> On Tue, Mar 5, 2024 at 7:48 AM Sumit Garg wrote:
> >
> > Hi Adam,
> >
> > On Wed, 28 Feb 2024 at 12:29, Sumit Garg wrote:
> > >
> > > Hi Adam,
> > >
> > > On Wed, 28 Feb 2024 at 04:42, Adam Ford wrote:
> > > >
> > > > On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg
> > > > wrote:
> > > > >
> > > > > Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs PCIe
> > > > > PHY initialization moved to this standalone PHY driver.
> > > > >
> > > > > Inspired from counterpart Linux kernel v6.8-rc3 driver:
> > > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c.
> > > >
> > > > I have a PCIe device that works just fine in Linux. I have applied
> > > > your series an enabled the same config options as you did along with
> > > > some others to resolve some build issues.
> > > >
> > > > Any ideas how to address:
> > > >
> > > > nxp_imx8_pcie_phy pcie-phy@32f0: PHY: Failed to power on
> > > > pcie-phy@32f0: -110.
> > > >
> > > > My PHY node looks like this
> > > >
> > > > _phy {
> > > > fsl,refclk-pad-mode = ;
> > > > clocks = <_refclk>;
> > > > clock-names = "ref";
> > > > status = "okay";
> > > > };
> > > >
> > > > The pcie_refcllk is defined as a 100MHz fixed clock in U-Boot. clk
> > > > dump shows it to be:
> > > >
> > > > 10|-- clock-pcie
> > > >
> > >
> > > I suppose that's an EVK board, try enabling MPCIE_3V3 regulator
> > > required for EVK board via following patch:
> > >
> > > diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> > > index 7856823c9188..32fd2cb05d4b 100644
> > > --- a/drivers/pci/pcie_dw_imx.c
> > > +++ b/drivers/pci/pcie_dw_imx.c
> > > @@ -17,6 +17,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -158,6 +159,8 @@ static int pcie_dw_imx_probe(struct udevice *dev)
> > > struct pci_controller *hose = dev_get_uclass_priv(ctlr);
> > > int ret;
> > >
> > > + regulator_autoset_by_name("MPCIE_3V3", NULL);
I think you should search the device tree for "vpcie-supply" and
enable the corresponding regulator, because is more flexible than
hard-coding regulator names. This is also more of a standard practice.
> > > +
> > > ret = imx_pcie_assert_core_reset(priv);
> > > if (ret) {
> > > dev_err(dev, "failed to assert core reset\n");
> > >
> >
> > Were you able to give a retry with the above diff?
>
> Not yet, but I'll try to do it tonight.
That didn't work for me. I am using a Beacon Embedded kit which does
not use a regulator, so this had no impact, but I think having the
vpcie-supply regulator is a good idea.
I'll investigate a bit more and let you know if I make any progress.
adam
>
> adam
> >
> > -Sumit
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On Tue Mar 5, 2024 at 7:54 PM CET, Marek Vasut wrote:
> On 3/5/24 5:55 PM, Michael Walle wrote:
>
> [...]
>
> >> Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
> >> Linux, since Linux that is booted afterward then gets a device that has
> >> locking scheme configured in a way that Linux expects and can operate.
> >>
> >> Better yet, if some old LTS version of the Linux kernel is in use, it
> >> will also work correctly, because this patch will configure the SPI NOR
> >> locking scheme to what Linux expects it to be, before the SPI NOR is
> >> handed over to that old kernel.
> >
> > Agreed, but it should *not* be done automatically and nor
> > unconditionally. Please don't just overwrite any locking bits just
> > because there is one flash which have it set.
>
> The unlock code is not triggered unconditionally, it is protected by
>
> if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
>
> Kconfig option, so this can be turned on/off in board config already.
> >>>
> >>> Ahh, OK then :)
> >>>
> >>> But keep in mind that enabling this option is foobar and I've gone
> >>> lengths to eliminate it in linux. And actually made that option in
> >>> u-boot.
> >>>
> >>> See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
> >>> are non-volatile").
> >>
> >> So, how shall we proceed here?
> >
> > Regarding this patch, I think it's fine. It will unlock the whole
> > flash as advertised.
>
> This change won't unlock the flash, it will switch to the supported
> locking scheme, one which can then be used to unlock the flash.
I can't follow you here. The code is added right below the
write_sr(0), which will clear all the BP bits, thus unlocking
everything if WPS=0. Therefore, no locking will be enabled anymore
afterwards. What did I miss?
> > But u-boot should really consider making that a "default n" option.
> > And most likely adding =y to every existing defconfig out there so
> > that at least new boards will benefit from it.
>
> Yes, I agree with that.
>
> >> The way I see this, if Linux ever implements this scheme, Linux can set
> >> the SR3 WPS bit as needed, it does not matter which way bootloader sets
> >> the bit as the protection bits are not cleared when the bit is cleared,
> >> they seem to be stored elsewhere.
> >
> > On each reboot you'd wear out that cell with two erases/writes.
> > That's another reason why that whole unlocking thing is foobar for
> > non-volatile bits. For me, non-volatile bits are for provisioning,
> > so during a normal boot they should not be touched at all. Just
> > during board manufacturing or because the user actively want to
> > protect something.
>
> That is what happens here, the write to clear the bit is triggered only
> if the bit is set , so OK .
>
> And if Linux wants to use the new locking scheme, then the bootloader
> should ideally be updated to match, i.e. SPI_FLASH_UNLOCK_ALL=n etc, so
> that is also OK .
I'd argue if one wants to use the locking at all, you have to set
UNLOCK_ALL=n. Otherwise, the bootloader might come alone and just
clear your locking bits again. Clearing the WPS bit there is just
one more thing which IMHO doesn't make much sense.
> In other words, there should be no writes into the non-volatile bits,
> unless U-Boot and Linux disagree on the locking scheme,
Agreed.
> in which case
> writes are unavoidable (if you want unlock to work in both projects).
But this should only happen if the user want to change the locking
at all. u-boot should not just do "oh this bit is set, I'm clearing
it" during SPI flash probe. Again, I'm not caring much if this is
guarded by the UNLOCK_ALL=y, because u-boot is already doing "oh the
BP bits are set, lets clear em".
> > If you clear this bit during the unlock all command, all the locking
> > bits are cleared anyway. Or do you mean, the individual bits are
> > still retained?
>
> The lock bits themselves are retained, this SR3 WPS only selects which
> of those bits take effect, whether the SR ones (standard locking scheme)
> or the per-page ones (winbond custom locking scheme).
Ok. So switching back to WPS=1 might come with some suprises :)
-michael
> >> But, if Linux starts to use SR3 WPS, then U-Boot should be updated to
> >> match, i.e. both projects should agree on the locking scheme, so that
> >> there won't be a situation where on the same device, one project uses
> >> one scheme, the other project uses another scheme. I think this would
> >> technically work, but it would be horrible from the user perspective.
> >> And if that happens, both projects should then be updated in lockstep
> >> and this UNLOCK_ALL should be disabled for such a setup then.
> >
> > If you don't touch it, I don't think you have a problem here. u-boot
> > and linux can support different schemes, as long as the user is
> > aware of that. I.e. if they want to lock a region and the flash is
> > configured in a
Re: [PATCH] doc: board: starfive: Fix paths in the bash block
On 3/4/24 23:15, Ivan Orlov wrote: From the current documentation it is not entirely obvious where to take some of the u-boot build artifacts in order to flash them to the sd card. Extend the "Program the SD card" block by providing relative paths to the jh7110-starfive-visionfive-2.dtb and u-boot-spl.bin.normal.out files. Add "$(linux_image_dir)/" prefix to the Image.gz and initramfs.cpio.gz files in order to provide some information about where they could be taken from. Signed-off-by: Ivan Orlov --- doc/board/starfive/visionfive2.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/board/starfive/visionfive2.rst b/doc/board/starfive/visionfive2.rst index abda8ac21b..031d66fbfb 100644 --- a/doc/board/starfive/visionfive2.rst +++ b/doc/board/starfive/visionfive2.rst @@ -103,15 +103,15 @@ Program the SD card .. code-block:: bash - sudo dd if=u-boot-spl.bin.normal.out of=/dev/sdb1 + sudo dd if=spl/u-boot-spl.bin.normal.out of=/dev/sdb1 sudo dd if=u-boot.itb of=/dev/sdb2 sudo mount /dev/sdb3 /mnt/ Following the instructions the partition in not formatted. You won't be able to mount it anywhere. Looking at the boot log the author FAT formatted the drive which is not recommendable. - sudo cp u-boot-spl.bin.normal.out /mnt/ + sudo cp spl/u-boot-spl.bin.normal.out /mnt/ sudo cp u-boot.itb /mnt/ - sudo cp Image.gz /mnt/ - sudo cp initramfs.cpio.gz /mnt/ - sudo cp jh7110-starfive-visionfive-2.dtb /mnt/ + sudo cp $(linux_image_dir)/Image.gz /mnt/ + sudo cp $(linux_image_dir)/initramfs.cpio.gz /mnt/ I have no clue why all users should copy the kernel to the root partition on the SD card. If you have a Linux installation on the SD-card, you want the kernel in boot/. But this board boots fine without any SD-card from NVMe, USB, or eMMC. + sudo cp arch/riscv/dts/jh7110-starfive-visionfive-2.dtb /mnt/ Copying the U-Boot device-tree makes no sense it is already available at $fdtcontroladdr. If you ever wanted to copy a device-tree, it should be the one provided with the kernel. This whole section is rather misleading for inexperienced users who just want to boot a Linux distro on the board. Best regards Heinrich sudo umount /mnt Booting
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On 3/5/24 5:55 PM, Michael Walle wrote:
[...]
Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
Linux, since Linux that is booted afterward then gets a device that has
locking scheme configured in a way that Linux expects and can operate.
Better yet, if some old LTS version of the Linux kernel is in use, it
will also work correctly, because this patch will configure the SPI NOR
locking scheme to what Linux expects it to be, before the SPI NOR is
handed over to that old kernel.
Agreed, but it should *not* be done automatically and nor
unconditionally. Please don't just overwrite any locking bits just
because there is one flash which have it set.
The unlock code is not triggered unconditionally, it is protected by
if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
Kconfig option, so this can be turned on/off in board config already.
Ahh, OK then :)
But keep in mind that enabling this option is foobar and I've gone
lengths to eliminate it in linux. And actually made that option in
u-boot.
See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
are non-volatile").
So, how shall we proceed here?
Regarding this patch, I think it's fine. It will unlock the whole
flash as advertised.
This change won't unlock the flash, it will switch to the supported
locking scheme, one which can then be used to unlock the flash.
But u-boot should really consider making that a "default n" option.
And most likely adding =y to every existing defconfig out there so
that at least new boards will benefit from it.
Yes, I agree with that.
The way I see this, if Linux ever implements this scheme, Linux can set
the SR3 WPS bit as needed, it does not matter which way bootloader sets
the bit as the protection bits are not cleared when the bit is cleared,
they seem to be stored elsewhere.
On each reboot you'd wear out that cell with two erases/writes.
That's another reason why that whole unlocking thing is foobar for
non-volatile bits. For me, non-volatile bits are for provisioning,
so during a normal boot they should not be touched at all. Just
during board manufacturing or because the user actively want to
protect something.
That is what happens here, the write to clear the bit is triggered only
if the bit is set , so OK .
And if Linux wants to use the new locking scheme, then the bootloader
should ideally be updated to match, i.e. SPI_FLASH_UNLOCK_ALL=n etc, so
that is also OK .
In other words, there should be no writes into the non-volatile bits,
unless U-Boot and Linux disagree on the locking scheme, in which case
writes are unavoidable (if you want unlock to work in both projects).
If you clear this bit during the unlock all command, all the locking
bits are cleared anyway. Or do you mean, the individual bits are
still retained?
The lock bits themselves are retained, this SR3 WPS only selects which
of those bits take effect, whether the SR ones (standard locking scheme)
or the per-page ones (winbond custom locking scheme).
But, if Linux starts to use SR3 WPS, then U-Boot should be updated to
match, i.e. both projects should agree on the locking scheme, so that
there won't be a situation where on the same device, one project uses
one scheme, the other project uses another scheme. I think this would
technically work, but it would be horrible from the user perspective.
And if that happens, both projects should then be updated in lockstep
and this UNLOCK_ALL should be disabled for such a setup then.
If you don't touch it, I don't think you have a problem here. u-boot
and linux can support different schemes, as long as the user is
aware of that. I.e. if they want to lock a region and the flash is
configured in a mode which isn't supported in u-boot (or linux) it
should be rejected. There might of course be a command to switch the
scheme if someone want to do so.
That is why I wrote that it is technically possible, but probably not a
good idea because it is inconsistent and therefore error prone.
[PATCH 2/2] doc: fix incorrect path Documentation
When copying the build system for Linux we missed to replace some
instances of 'Documentation' by 'doc'.
Signed-off-by: Heinrich Schuchardt
---
doc/sphinx/maintainers_include.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/sphinx/maintainers_include.py
b/doc/sphinx/maintainers_include.py
index 6cee52cbb39..13557d3d3c2 100755
--- a/doc/sphinx/maintainers_include.py
+++ b/doc/sphinx/maintainers_include.py
@@ -78,8 +78,8 @@ class MaintainersInclude(Include):
# Drop needless input whitespace.
line = line.rstrip()
-# Linkify all non-wildcard refs to ReST files in Documentation/.
-pat = r'(Documentation/([^\s\?\*]*)\.rst)'
+# Linkify all non-wildcard refs to ReST files in doc/.
+pat = r'(doc/([^\s\?\*]*)\.rst)'
m = re.search(pat, line)
if m:
# maintainers.rst is in a subdirectory, so include "../".
@@ -177,11 +177,11 @@ class MaintainersInclude(Include):
if not self.state.document.settings.file_insertion_enabled:
raise self.warning('"%s" directive disabled.' % self.name)
-# Walk up source path directories to find Documentation/../
+# Walk up source path directories to find doc/../
path = self.state_machine.document.attributes['source']
path = os.path.realpath(path)
tail = path
-while tail != "Documentation" and tail != "":
+while tail != "doc" and tail != "":
(path, tail) = os.path.split(path)
# Append "MAINTAINERS"
--
2.43.0
[PATCH 1/2] doc/sphinx: fix Python string escapes
From: Benjamin Gray
Python 3.6 introduced a DeprecationWarning for invalid escape sequences.
This is upgraded to a SyntaxWarning in Python 3.12, and will eventually
be a syntax error.
Fix these now to get ahead of it before it's an error.
Signed-off-by: Benjamin Gray
Message-ID: <20230912060801.95533-3-bg...@linux.ibm.com>
Signed-off-by: Jonathan Corbet
Adapted for U-Boot
Signed-off-by: Heinrich Schuchardt
---
doc/sphinx/cdomain.py | 2 +-
doc/sphinx/kernel_abi.py | 2 +-
doc/sphinx/kerneldoc.py | 2 +-
doc/sphinx/maintainers_include.py | 8
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/sphinx/cdomain.py b/doc/sphinx/cdomain.py
index 014a5229e57..491a7ed5f47 100644
--- a/doc/sphinx/cdomain.py
+++ b/doc/sphinx/cdomain.py
@@ -93,7 +93,7 @@ def markup_ctype_refs(match):
#
RE_expr = re.compile(r':c:(expr|texpr):`([^\`]+)`')
def markup_c_expr(match):
-return '\ ``' + match.group(2) + '``\ '
+return '\\ ``' + match.group(2) + '``\\ '
#
# Parse Sphinx 3.x C markups, replacing them by backward-compatible ones
diff --git a/doc/sphinx/kernel_abi.py b/doc/sphinx/kernel_abi.py
index f3da859c987..32c50e496b5 100644
--- a/doc/sphinx/kernel_abi.py
+++ b/doc/sphinx/kernel_abi.py
@@ -147,7 +147,7 @@ class KernelCmd(Directive):
code_block += "\n" + l
lines = code_block + "\n\n"
-line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$")
+line_regex = re.compile(r"^#define LINENO (\S+)\#([0-9]+)$")
ln = 0
n = 0
f = fname
diff --git a/doc/sphinx/kerneldoc.py b/doc/sphinx/kerneldoc.py
index 01a55429c57..bc8bb9e5125 100644
--- a/doc/sphinx/kerneldoc.py
+++ b/doc/sphinx/kerneldoc.py
@@ -130,7 +130,7 @@ class KernelDocDirective(Directive):
result = ViewList()
lineoffset = 0;
-line_regex = re.compile("^#define LINENO ([0-9]+)$")
+line_regex = re.compile(r"^#define LINENO ([0-9]+)$")
for line in lines:
match = line_regex.search(line)
if match:
diff --git a/doc/sphinx/maintainers_include.py
b/doc/sphinx/maintainers_include.py
index dc8fed48d3c..6cee52cbb39 100755
--- a/doc/sphinx/maintainers_include.py
+++ b/doc/sphinx/maintainers_include.py
@@ -79,7 +79,7 @@ class MaintainersInclude(Include):
line = line.rstrip()
# Linkify all non-wildcard refs to ReST files in Documentation/.
-pat = '(Documentation/([^\s\?\*]*)\.rst)'
+pat = r'(Documentation/([^\s\?\*]*)\.rst)'
m = re.search(pat, line)
if m:
# maintainers.rst is in a subdirectory, so include "../".
@@ -92,11 +92,11 @@ class MaintainersInclude(Include):
output = "| %s" % (line.replace("\\", ""))
# Look for and record field letter to field name mappings:
# R: Designated *reviewer*: FullName
-m = re.search("\s(\S):\s", line)
+m = re.search(r"\s(\S):\s", line)
if m:
field_letter = m.group(1)
if field_letter and not field_letter in fields:
-m = re.search("\*([^\*]+)\*", line)
+m = re.search(r"\*([^\*]+)\*", line)
if m:
fields[field_letter] = m.group(1)
elif subsystems:
@@ -114,7 +114,7 @@ class MaintainersInclude(Include):
field_content = ""
# Collapse whitespace in subsystem name.
-heading = re.sub("\s+", " ", line)
+heading = re.sub(r"\s+", " ", line)
output = output + "%s\n%s" % (heading, "~" * len(heading))
field_prev = ""
else:
--
2.43.0
Re: [PATCH v1] riscv: cpu: improve multi-letter extension detection in supports_extension()
On Tue, Mar 05, 2024 at 09:10:59AM +0100, Heinrich Schuchardt wrote: > On 3/5/24 08:54, Conor Dooley wrote: > > On Tue, Mar 05, 2024 at 08:34:20AM +0100, Heinrich Schuchardt wrote: > > > On 3/5/24 00:28, Conor Dooley wrote: > > > > From: Conor Dooley > > > According to > > > https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc the > > > ISA string is case insensitive. Why can we assume here that it is lower > > > case? > > > > The binding does not allow upper-case. > > Ok. That is in Linux' > Documentation/devicetree/bindings/riscv/extensions.yaml. Right. I should've linked to that, sorry. signature.asc Description: PGP signature
Re: [PATCH v2 2/2] board: phycore_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1
On Mon, Mar 4, 2024 at 1:04 PM Benjamin Hahn wrote:
> - ret = phytec_get_rev(NULL);
> - if (ret >= 3 && ret != PHYTEC_EEPROM_INVAL) {
> + u8 rev = phytec_get_rev(NULL);
> + u8 somtyp = phytec_get_som_type(NULL);
Nitpick: Better to spell out 'somtype' or 'som_type' to make it clearer.
"typ" usually means 'typical'.
Re: [PATCH v2 1/2] board: phytec: common: phytec_som_detection: Add phytec_get_som_type
On Mon, Mar 4, 2024 at 1:04 PM Benjamin Hahn wrote:
> +enum phytec_som_type_str {
> + PCM = 0,
> + PCL,
> + KSM,
> + KSP,
> +};
To avoid potential name clashes in the future, I suggest adding a prefix like:
SOM_TYPE_PCM = 0,
SOM_TYPE_PCL,
...
> +
> static const char * const phytec_som_type_str[] = {
> "PCM",
> "PCL",
> @@ -67,5 +74,6 @@ void __maybe_unused phytec_print_som_info(struct
> phytec_eeprom_data *data);
>
> char * __maybe_unused phytec_get_opt(struct phytec_eeprom_data *data);
> u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data *data);
> +u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data);
>
> #endif /* _PHYTEC_SOM_DETECTION_H */
>
> --
> 2.34.1
>
Re: [PATCH] drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node
On Mon, Mar 4, 2024 at 8:49 AM Benjamin Hahn wrote: > > The polling rate is already specified in some devicetrees, like > imx8mp.dtsi for example, but was not selected so far. For the > trippoints, the cpu-thermal node is used. Also get the polling rate from > this node. Use the default of 5000ms if the polling rate should not be > specified in the devicetree. > > NOTE: The polling rate from the devicetree will be used after this > patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for > example. > > Signed-off-by: Benjamin Hahn Reviewed-by: Fabio Estevam
Re: [PATCH v2] Makefile: use shell to calculate map_size
A colleague made me aware that the '[ -n "$$end" ]' is not necessary since
'read' already returns an exit code.
v3 inc
On Mon, 4 Mar 2024 21:38:56 +0100
"Leon M. Busch-George" wrote:
> From: "Leon M. Busch-George"
>
> The error message "bc: command not found" is easily missed since the
> build continues.
> bc is not a part of coreutils or base-devel. POSIX sh can also do the
> calculation.
>
> Signed-off-by: Leon M. Busch-George
> ---
> Makefile | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index a2bc9d5903..e8e794368e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1275,10 +1275,15 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
> binary_size_check: u-boot-nodtb.bin FORCE
> @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print
> $$1}') ; \ map_size=$(shell cat u-boot.map | \
> - awk '/_image_copy_start/ {start = $$1}
> /_image_binary_end/ {end = $$1} END {if (start != "" && end != "")
> print "ibase=16; " toupper(end) " - " toupper(start)}' \
> - | sed 's/0X//g' \
> - | bc); \
> - if [ "" != "$$map_size" ]; then \
> + awk ' \
> + /_image_copy_start/ { start = $$1 } \
> + /_image_binary_end/ { end = $$1 } \
> + END { \
> + if (start != "" && end != "") \
> + print end " " start; \
> + }' \
> + | sh -c 'read end start; [ -n "$$end" ] && echo
> $$((end - start))'); \
> + if [ -n "$$map_size" ]; then \
> if test $$map_size -ne $$file_size; then \
> echo "u-boot.map shows a binary size of
> $$map_size" >&2 ; \ echo " but u-boot-nodtb.bin shows $$file_size"
> >&2 ; \
Re: [PATCH] qcom_defconfig: Enable ethernet and I2C support
On Mon, 19 Feb 2024 14:11:44 +0530, Sumit Garg wrote: > QCS404 supports Synopsys Designware Ethernet QOS IP and we already have > the corresponding glue layer present upstream as: > drivers/net/dwc_eth_qos_qcom.c. So enable corresponding support. > > Along with that it is possible for Qualcomm platforms to retrieve MAC > address from I2C eeprom present on board. So enable corresponding > support as well. > > [...] Applied, thanks! [1/1] qcom_defconfig: Enable ethernet and I2C support commit: b307c5d45dcd1e086a3b28affd1a1006f35334b4 Best regards, -- // Caleb (they/them)
Re: [PATCH 1/2] arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL
On 3/5/2024 11:04 PM, Bryan Brattlof wrote:
> On March 5, 2024 thus sayeth Vignesh Raghavendra:
>>
>> On 05/03/24 01:57, Bryan Brattlof wrote:
>>> Hey Vignesh!
>>>
>>> On March 4, 2024 thus sayeth Vignesh Raghavendra:
Hi Wadim,
On 26/02/24 19:00, Wadim Egorov wrote:
> Texas Instruments has begun enabling security settings on the SoCs it
> produces to instruct ROM and TIFS to begin protecting the Security
> Management Subsystem (SMS) from other binaries we load into the chip by
> default.
>
> One way ROM and TIFS do this is by enabling firewalls to protect the
> OCSRAM and HSM RAM regions they're using during bootup.
>
> The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
> itself from the main domain applications. This means the 'bootindex'
> value in HSM RAM, left by ROM to indicate if we're using the primary
> or secondary boot-method, must be moved to OCSRAM (that TIFS has open
> for us) before we make the jump to the main domain so the main domain's
> bootloaders can keep access to this information.
>
> Based on commit
> b672e8581070 ("arm: mach-k3: copy bootindex to OCRAM for main domain
> SPL")
>
FYI, this is mostly a problem in non SPL flow (TI prosperity SBL for
example) where HSM RAM would be used by HSM firmware. This should be a
issue in R5 SPL flow. Do you see any issues today? If so, whats the
TIFS firmware being used?
> Signed-off-by: Wadim Egorov
> ---
> arch/arm/mach-k3/Kconfig | 3 ++-
> arch/arm/mach-k3/am625_init.c | 15 +--
> arch/arm/mach-k3/include/mach/am62_hardware.h | 15 +++
> 3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index 03898424c9..f5d06593f7 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -75,7 +75,8 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
> default 0x41cffbfc if SOC_K3_J721E
> default 0x41cfdbfc if SOC_K3_J721S2
> default 0x701bebfc if SOC_K3_AM642
> - default 0x43c3f290 if SOC_K3_AM625
> + default 0x43c3f290 if SOC_K3_AM625 && CPU_V7R
> + default 0x7000f290 if SOC_K3_AM625 && ARM64
> default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
> default 0x7000f290 if SOC_K3_AM62A7 && ARM64
> help
> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> index 6c96e88114..67cf63b103 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -35,8 +35,10 @@ static struct rom_extended_boot_data bootdata
> __section(".data");
> static void store_boot_info_from_rom(void)
> {
> bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
> - memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> -sizeof(struct rom_extended_boot_data));
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> +sizeof(struct rom_extended_boot_data));
> + }
> }
>
> static void ctrl_mmr_unlock(void)
> @@ -175,6 +177,15 @@ void board_init_f(ulong dummy)
> k3_sysfw_loader(true, NULL, NULL);
> }
>
> +#if defined(CONFIG_CPU_V7R)
> + /*
> + * Relocate boot information to OCRAM (after TIFS has opend this
> + * region for us) so the next bootloader stages can keep access to
> + * primary vs backup bootmodes.
> + */
> + writel(bootindex, K3_BOOT_PARAM_TABLE_INDEX_OCRAM);
> +#endif
> +
> /*
>* Force probe of clk_k3 driver here to ensure basic default clock
>* configuration is always done.
> diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h
> b/arch/arm/mach-k3/include/mach/am62_hardware.h
> index 54380f36e1..9f504f4642 100644
> --- a/arch/arm/mach-k3/include/mach/am62_hardware.h
> +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
> @@ -76,8 +76,23 @@
> #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE +
> 0x18170)
>
> #define ROM_EXTENDED_BOOT_DATA_INFO 0x43c3f1e0
> +#define K3_BOOT_PARAM_TABLE_INDEX_OCRAM 0x7000F290
>
> +/*
> + * During the boot process ROM will kill anything that writes to OCSRAM.
R5 ROM is long gone when R5 SPL starts, how would it kill anything?
>>> Looks like this was based on my patch long ago for the AM62Ax family.
>>> From what little I remember about this was ROM is leaving behind a
>>> firewall that we need TIFS's help to bring down for us. So I just
>>> blamed ROM
>> Thats true. ROM does bare minimum and so wont open up firewall around
>> main SRAM. but TIFS does, so you should be able to access this region
>> post k3_sysfw_loader().
>>
>>> IDK if this is an issue for the AM62x family
Re: [PATCH 1/2] arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL
On March 5, 2024 thus sayeth Vignesh Raghavendra:
>
>
> On 05/03/24 01:57, Bryan Brattlof wrote:
> > Hey Vignesh!
> >
> > On March 4, 2024 thus sayeth Vignesh Raghavendra:
> >> Hi Wadim,
> >>
> >> On 26/02/24 19:00, Wadim Egorov wrote:
> >>> Texas Instruments has begun enabling security settings on the SoCs it
> >>> produces to instruct ROM and TIFS to begin protecting the Security
> >>> Management Subsystem (SMS) from other binaries we load into the chip by
> >>> default.
> >>>
> >>> One way ROM and TIFS do this is by enabling firewalls to protect the
> >>> OCSRAM and HSM RAM regions they're using during bootup.
> >>>
> >>> The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
> >>> itself from the main domain applications. This means the 'bootindex'
> >>> value in HSM RAM, left by ROM to indicate if we're using the primary
> >>> or secondary boot-method, must be moved to OCSRAM (that TIFS has open
> >>> for us) before we make the jump to the main domain so the main domain's
> >>> bootloaders can keep access to this information.
> >>>
> >>> Based on commit
> >>> b672e8581070 ("arm: mach-k3: copy bootindex to OCRAM for main domain
> >>> SPL")
> >>>
> >>
> >> FYI, this is mostly a problem in non SPL flow (TI prosperity SBL for
> >> example) where HSM RAM would be used by HSM firmware. This should be a
> >> issue in R5 SPL flow. Do you see any issues today? If so, whats the
> >> TIFS firmware being used?
> >>
> >>> Signed-off-by: Wadim Egorov
> >>> ---
> >>> arch/arm/mach-k3/Kconfig | 3 ++-
> >>> arch/arm/mach-k3/am625_init.c | 15 +--
> >>> arch/arm/mach-k3/include/mach/am62_hardware.h | 15 +++
> >>> 3 files changed, 30 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> >>> index 03898424c9..f5d06593f7 100644
> >>> --- a/arch/arm/mach-k3/Kconfig
> >>> +++ b/arch/arm/mach-k3/Kconfig
> >>> @@ -75,7 +75,8 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
> >>> default 0x41cffbfc if SOC_K3_J721E
> >>> default 0x41cfdbfc if SOC_K3_J721S2
> >>> default 0x701bebfc if SOC_K3_AM642
> >>> - default 0x43c3f290 if SOC_K3_AM625
> >>> + default 0x43c3f290 if SOC_K3_AM625 && CPU_V7R
> >>> + default 0x7000f290 if SOC_K3_AM625 && ARM64
> >>> default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
> >>> default 0x7000f290 if SOC_K3_AM62A7 && ARM64
> >>> help
> >>> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> >>> index 6c96e88114..67cf63b103 100644
> >>> --- a/arch/arm/mach-k3/am625_init.c
> >>> +++ b/arch/arm/mach-k3/am625_init.c
> >>> @@ -35,8 +35,10 @@ static struct rom_extended_boot_data bootdata
> >>> __section(".data");
> >>> static void store_boot_info_from_rom(void)
> >>> {
> >>> bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
> >>> - memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> >>> -sizeof(struct rom_extended_boot_data));
> >>> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> >>> + memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> >>> +sizeof(struct rom_extended_boot_data));
> >>> + }
> >>> }
> >>>
> >>> static void ctrl_mmr_unlock(void)
> >>> @@ -175,6 +177,15 @@ void board_init_f(ulong dummy)
> >>> k3_sysfw_loader(true, NULL, NULL);
> >>> }
> >>>
> >>> +#if defined(CONFIG_CPU_V7R)
> >>> + /*
> >>> + * Relocate boot information to OCRAM (after TIFS has opend this
> >>> + * region for us) so the next bootloader stages can keep access to
> >>> + * primary vs backup bootmodes.
> >>> + */
> >>> + writel(bootindex, K3_BOOT_PARAM_TABLE_INDEX_OCRAM);
> >>> +#endif
> >>> +
> >>> /*
> >>>* Force probe of clk_k3 driver here to ensure basic default clock
> >>>* configuration is always done.
> >>> diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h
> >>> b/arch/arm/mach-k3/include/mach/am62_hardware.h
> >>> index 54380f36e1..9f504f4642 100644
> >>> --- a/arch/arm/mach-k3/include/mach/am62_hardware.h
> >>> +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
> >>> @@ -76,8 +76,23 @@
> >>> #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE +
> >>> 0x18170)
> >>>
> >>> #define ROM_EXTENDED_BOOT_DATA_INFO 0x43c3f1e0
> >>> +#define K3_BOOT_PARAM_TABLE_INDEX_OCRAM 0x7000F290
> >>>
> >>> +/*
> >>> + * During the boot process ROM will kill anything that writes to OCSRAM.
> >>
> >> R5 ROM is long gone when R5 SPL starts, how would it kill anything?
> >
> > Looks like this was based on my patch long ago for the AM62Ax family.
> > From what little I remember about this was ROM is leaving behind a
> > firewall that we need TIFS's help to bring down for us. So I just
> > blamed ROM ;)
>
> Thats true. ROM does bare minimum and so wont open up firewall around
> main SRAM. but TIFS does, so you should be able to access this region
> post k3_sysfw_loader().
>
> >
> > IDK if this is an issue for the AM62x family though.
> >
>
> It might
Re: [PATCH] configs: rockchip: rock5a: enable environment
On 2024-03-05 14:45, Trevor Woerner wrote: > On Tue 2024-03-05 @ 10:17:10 AM, Jonas Karlman wrote: >> Hi, >> >> On 2024-03-05 06:40, Eugen Hristev wrote: >>> On 3/5/24 04:10, Trevor Woerner wrote: Following the pattern of other Rockchip devices, enable the U-Boot environment to be stored in MMC. This patch specifically assumes the environment will be stored on the SDcard. Signed-off-by: Trevor Woerner --- configs/rock5a-rk3588s_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig index a6471a519514..ac6411667d9a 100644 --- a/configs/rock5a-rk3588s_defconfig +++ b/configs/rock5a-rk3588s_defconfig @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0 +CONFIG_ENV_SIZE=0x8000 CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a" CONFIG_ROCKCHIP_RK3588=y CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y @@ -48,6 +49,8 @@ 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_ENV_IS_IN_MMC=y +CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y >>> >>> >>> Hi Trevor, >>> >>> What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash >>> ? >> >> Agree, we should not blindly enable env and expect that it can be stored >> on sd-card. If anything, it should preferably be saved/loaded from the >> device where TPL/SPL was booted from. >> >> Personally I always run my devices with ENV_IS_NOWHERE, with standard >> boot and extlinux or efi as the preferred way to boot, I do not see why >> normal end-users with a single OS really have a need for a saved env, >> please educate me :-) > > I am the maintainer of the meta-rockchip Yocto layer[1]. Yocto uses a > nifty tool called 'wic' to layout images (dos/gpt partitioning, optionally > formatting partitions, optionally installing things into those partitions)[2]. > The partitioning layout that we follow is the one that is recommended by > Rockchip itself[3] with 2 exceptions: > - we don't hide any of the partitions from the partition table > - we've combined /boot into the root partition (for reasons I'll explain > later) > > Under the Rockchip partitioning, the U-Boot environment is stored in partition > 5, at offset 0x0003.f800, and has a size of 0x.8000. Not sure you should look too much at the Rockchip partitioning, not sure it is something to promote for mainline Linux and U-Boot usage. The partitions is not correct/relevant, especially for aarch64. For mainline the following offsets are typically only used: - 0x8000: TPL+SPL - up to around 256+256 KiB - 0x003F8000: optional U-Boot env - 0x0080: FIT with U-Boot proper + TF-A and/or OPTEE, or U-Boot proper in legacy image format - 0x0100+: free use It is highly recommended to write the generated u-boot-rockchip.bin to sector 0x40 of mmc to get all the U-Boot related offsets correct as defined in board defconfig. To me the traditional Rockchip partitioning scheme does not really fill any purpose with mainline Linux and U-Boot, please enlighten me :-) One thing that vendor U-Boot does that possible could be adopted for mainline U-Boot is that it will locate FIT based on a GPT partition named "uboot" and fallback to traditional sector 0x4000. The offsets and size of traditional Rockchip partitioning scheme is no longer that important for vendor U-Boot/Linux. It is also possible to reclaim some of the wasted space by putting FIT at a different location, e.g: - 0x8000: TPL+SPL - up to around 256+256 KiB - 0x00088000: FIT with U-Boot proper + TF-A - up to 3520 KiB - 0x003F8000: optional U-Boot env - 0x0040+: free use > > I don't own every Rockchip board, but I have a bunch of them (thanks to some > generous donations!). I've created a spreadsheet that lists the ones supported > by meta-rockchip and their environment variable U-Boot configurations > (locations, offsets, sizes). Most of them follow the Rockchip recommended > partitioning layout with regards to storing the environment. This set of > patches closes that gap, at least for the ones supported by meta-rockchip. > > One of the things that I want to do next with meta-rockchip is to provide > an easy way for users to enable some sort of A/B OTA update strategy. > Currently, enabling an A/B update mechanism for any board (Rockchip or not) > is a non-trivial exercise. Every A/B update mechanism that I've looked at > requires (among other things) the bootloader to be able to store/retrieve > its environment from U-Boot itself (obviously) and also from Linux userspace > since it is the bootloader that ultimately
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On Tue Mar 5, 2024 at 5:28 PM CET, Marek Vasut wrote:
> On 3/5/24 4:53 PM, Michael Walle wrote:
> > On Tue Mar 5, 2024 at 4:37 PM CET, Marek Vasut wrote:
> >> On 3/5/24 1:50 PM, Michael Walle wrote:
> >>> On Tue Mar 5, 2024 at 1:31 PM CET, Marek Vasut wrote:
> On 3/5/24 9:55 AM, Michael Walle wrote:
> > On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote:
> >> Some Winbond SPI NORs have special SR3 register which is
> >> used among other things to control whether non-standard
> >> "Individual Block/Sector Write Protection" (WPS bit)
> >> locking scheme is activated. This non-standard locking
> >> scheme is not supported by either U-Boot or Linux SPI
> >> NOR stack so make sure it is disabled, otherwise the
> >> SPI NOR may appear locked for no obvious reason.
> >
> > I don't think it is a good idea to just disable the WPS bit.
> > Usually, that bit is non-volatile and the default is not set.
>
> Yes, that's right, the bit is non-volatile and should not be set unless
> the MTD stack can handle it correctly. Currently, neither U-Boot nor
> Linux does handle the bit at all, instead both attempt to use the
> standard SPI NOR locking scheme which is also implemented by this SPI
> NOR model and they both fail to unlock the SPI NOR that way.
>
> Note that the SR3 WPS bit only switches between two different locking
> schemes (unset = standard SPI NOR locking scheme, set = custom winbond
> locking scheme), setting SR3 WPS does not immediately imply the SPI NOR
> is locked, rather the opposite. Out of manufacturing, the SPI NOR is
> unlocked in either locking scheme. Depending on the SR3 WPS bit state,
> different commands are used to lock and unlock the SPI NOR.
>
> I recently ran across a device which had the SR3 WPS bit incorrectly set
> out of manufacturing of that device (i.e. before it was populated on a
> board at board manufacturer) and the device was locked using the custom
> locking scheme. I was not able to unlock or use that device because both
> U-Boot and Linux tried to use the standard scheme for that purpose.
> >>>
> >>> Still, I don't think it makes any sense, to disable that bit for all
> >>> winbond flashes just because there was one vendor which set it the
> >>> wrong way - or the board manufacturer didn't test it and programmed
> >>> the flash correctly.
> >>
> >> OK
> >>
> Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
> Linux, since Linux that is booted afterward then gets a device that has
> locking scheme configured in a way that Linux expects and can operate.
>
> Better yet, if some old LTS version of the Linux kernel is in use, it
> will also work correctly, because this patch will configure the SPI NOR
> locking scheme to what Linux expects it to be, before the SPI NOR is
> handed over to that old kernel.
> >>>
> >>> Agreed, but it should *not* be done automatically and nor
> >>> unconditionally. Please don't just overwrite any locking bits just
> >>> because there is one flash which have it set.
> >>
> >> The unlock code is not triggered unconditionally, it is protected by
> >>
> >> if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
> >>
> >> Kconfig option, so this can be turned on/off in board config already.
> >
> > Ahh, OK then :)
> >
> > But keep in mind that enabling this option is foobar and I've gone
> > lengths to eliminate it in linux. And actually made that option in
> > u-boot.
> >
> > See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
> > are non-volatile").
>
> So, how shall we proceed here?
Regarding this patch, I think it's fine. It will unlock the whole
flash as advertised.
But u-boot should really consider making that a "default n" option.
And most likely adding =y to every existing defconfig out there so
that at least new boards will benefit from it.
> The way I see this, if Linux ever implements this scheme, Linux can set
> the SR3 WPS bit as needed, it does not matter which way bootloader sets
> the bit as the protection bits are not cleared when the bit is cleared,
> they seem to be stored elsewhere.
On each reboot you'd wear out that cell with two erases/writes.
That's another reason why that whole unlocking thing is foobar for
non-volatile bits. For me, non-volatile bits are for provisioning,
so during a normal boot they should not be touched at all. Just
during board manufacturing or because the user actively want to
protect something.
If you clear this bit during the unlock all command, all the locking
bits are cleared anyway. Or do you mean, the individual bits are
still retained?
> But, if Linux starts to use SR3 WPS, then U-Boot should be updated to
> match, i.e. both projects should agree on the locking scheme, so that
> there won't be a situation where on the same device, one project uses
> one scheme, the other project uses
[PATCH v3] Makefile: use shell to calculate map_size
From: "Leon M. Busch-George"
The error message "bc: command not found" is easily missed since the
build continues.
bc is not a part of coreutils or base-devel. POSIX sh can also do the
calculation.
Signed-off-by: Leon M. Busch-George
---
Makefile | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index a2bc9d5903..0aef07ef3b 100644
--- a/Makefile
+++ b/Makefile
@@ -1275,10 +1275,15 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != "" && end != "") print "ibase=16; " toupper(end) " - "
toupper(start)}' \
- | sed 's/0X//g' \
- | bc); \
- if [ "" != "$$map_size" ]; then \
+ awk ' \
+ /_image_copy_start/ { start = $$1 } \
+ /_image_binary_end/ { end = $$1 } \
+ END { \
+ if (start != "" && end != "") \
+ print end " " start; \
+ }' \
+ | sh -c 'read end start && echo $$((end - start))'); \
+ if [ -n "$$map_size" ]; then \
if test $$map_size -ne $$file_size; then \
echo "u-boot.map shows a binary size of $$map_size" >&2
; \
echo " but u-boot-nodtb.bin shows $$file_size" >&2 ; \
--
2.44.0
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On 3/5/24 4:53 PM, Michael Walle wrote:
On Tue Mar 5, 2024 at 4:37 PM CET, Marek Vasut wrote:
On 3/5/24 1:50 PM, Michael Walle wrote:
Hi Marek,
Hi,
On Tue Mar 5, 2024 at 1:31 PM CET, Marek Vasut wrote:
On 3/5/24 9:55 AM, Michael Walle wrote:
On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote:
Some Winbond SPI NORs have special SR3 register which is
used among other things to control whether non-standard
"Individual Block/Sector Write Protection" (WPS bit)
locking scheme is activated. This non-standard locking
scheme is not supported by either U-Boot or Linux SPI
NOR stack so make sure it is disabled, otherwise the
SPI NOR may appear locked for no obvious reason.
I don't think it is a good idea to just disable the WPS bit.
Usually, that bit is non-volatile and the default is not set.
Yes, that's right, the bit is non-volatile and should not be set unless
the MTD stack can handle it correctly. Currently, neither U-Boot nor
Linux does handle the bit at all, instead both attempt to use the
standard SPI NOR locking scheme which is also implemented by this SPI
NOR model and they both fail to unlock the SPI NOR that way.
Note that the SR3 WPS bit only switches between two different locking
schemes (unset = standard SPI NOR locking scheme, set = custom winbond
locking scheme), setting SR3 WPS does not immediately imply the SPI NOR
is locked, rather the opposite. Out of manufacturing, the SPI NOR is
unlocked in either locking scheme. Depending on the SR3 WPS bit state,
different commands are used to lock and unlock the SPI NOR.
I recently ran across a device which had the SR3 WPS bit incorrectly set
out of manufacturing of that device (i.e. before it was populated on a
board at board manufacturer) and the device was locked using the custom
locking scheme. I was not able to unlock or use that device because both
U-Boot and Linux tried to use the standard scheme for that purpose.
Still, I don't think it makes any sense, to disable that bit for all
winbond flashes just because there was one vendor which set it the
wrong way - or the board manufacturer didn't test it and programmed
the flash correctly.
OK
Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
Linux, since Linux that is booted afterward then gets a device that has
locking scheme configured in a way that Linux expects and can operate.
Better yet, if some old LTS version of the Linux kernel is in use, it
will also work correctly, because this patch will configure the SPI NOR
locking scheme to what Linux expects it to be, before the SPI NOR is
handed over to that old kernel.
Agreed, but it should *not* be done automatically and nor
unconditionally. Please don't just overwrite any locking bits just
because there is one flash which have it set.
The unlock code is not triggered unconditionally, it is protected by
if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
Kconfig option, so this can be turned on/off in board config already.
Ahh, OK then :)
But keep in mind that enabling this option is foobar and I've gone
lengths to eliminate it in linux. And actually made that option in
u-boot.
See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
are non-volatile").
So, how shall we proceed here?
The way I see this, if Linux ever implements this scheme, Linux can set
the SR3 WPS bit as needed, it does not matter which way bootloader sets
the bit as the protection bits are not cleared when the bit is cleared,
they seem to be stored elsewhere.
But, if Linux starts to use SR3 WPS, then U-Boot should be updated to
match, i.e. both projects should agree on the locking scheme, so that
there won't be a situation where on the same device, one project uses
one scheme, the other project uses another scheme. I think this would
technically work, but it would be horrible from the user perspective.
And if that happens, both projects should then be updated in lockstep
and this UNLOCK_ALL should be disabled for such a setup then.
[PATCH v2] arm: dts: k3-am64: Move to OF_UPSTREAM
Enable OF_UPSTREAM for AM64-EVM and SK-AM64 boards. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.7-rc7).
Signed-off-by: Andrew Davis
---
Changes for v2:
- Rebased on latest -next to fix merge conflict
As suggested here[0].
[0] https://lore.kernel.org/all/20240304170814.GP1523872@bill-the-cat/
arch/arm/dts/Makefile |4 +-
arch/arm/dts/k3-am64-main.dtsi| 1546 -
arch/arm/dts/k3-am64-mcu.dtsi | 161 ---
arch/arm/dts/k3-am64-thermal.dtsi | 33 -
arch/arm/dts/k3-am64.dtsi | 100 --
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 110 --
arch/arm/dts/k3-am642-evm.dts | 690 ---
arch/arm/dts/k3-am642-r5-evm.dts | 24 -
arch/arm/dts/k3-am642-r5-sk.dts | 12 -
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 94 --
arch/arm/dts/k3-am642-sk.dts | 642 --
arch/arm/dts/k3-am642.dtsi| 66 --
arch/arm/dts/k3-am64x-binman.dtsi |6 +-
configs/am64x_evm_a53_defconfig |5 +-
14 files changed, 7 insertions(+), 3486 deletions(-)
delete mode 100644 arch/arm/dts/k3-am64-main.dtsi
delete mode 100644 arch/arm/dts/k3-am64-mcu.dtsi
delete mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
delete mode 100644 arch/arm/dts/k3-am64.dtsi
delete mode 100644 arch/arm/dts/k3-am642-evm.dts
delete mode 100644 arch/arm/dts/k3-am642-sk.dts
delete mode 100644 arch/arm/dts/k3-am642.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 971a4065faf..b97ff3b07ea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1417,9 +1417,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-r5-sk.dtb \
k3-j784s4-r5-evm.dtb
-dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
- k3-am642-r5-evm.dtb \
- k3-am642-sk.dtb \
+dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
k3-am642-r5-sk.dtb
dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
deleted file mode 100644
index 0df54a74182..000
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ /dev/null
@@ -1,1546 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Device Tree Source for AM642 SoC Family Main Domain peripherals
- *
- * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-#include
-#include
-
-/ {
- serdes_refclk: clock-cmnrefclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
- };
-};
-
-_main {
- oc_sram: sram@7000 {
- compatible = "mmio-sram";
- reg = <0x00 0x7000 0x00 0x20>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x00 0x7000 0x20>;
-
- tfa-sram@1c {
- reg = <0x1c 0x2>;
- };
-
- dmsc-sram@1e {
- reg = <0x1e 0x1c000>;
- };
-
- sproxy-sram@1fc000 {
- reg = <0x1fc000 0x4000>;
- };
- };
-
- main_conf: syscon@4300 {
- compatible = "ti,j721e-system-controller", "syscon",
"simple-mfd";
- reg = <0x0 0x4300 0x0 0x2>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x4300 0x2>;
-
- chipid@14 {
- compatible = "ti,am654-chipid";
- reg = <0x0014 0x4>;
- };
-
- serdes_ln_ctrl: mux-controller {
- compatible = "mmio-mux";
- #mux-control-cells = <1>;
- mux-reg-masks = <0x4080 0x3>; /* SERDES0 lane0 select */
- };
-
- phy_gmii_sel: phy@4044 {
- compatible = "ti,am654-phy-gmii-sel";
- reg = <0x4044 0x8>;
- #phy-cells = <1>;
- };
-
- epwm_tbclk: clock-controller@4140 {
- compatible = "ti,am64-epwm-tbclk";
- reg = <0x4130 0x4>;
- #clock-cells = <1>;
- };
- };
-
- gic500: interrupt-controller@180 {
- compatible = "arm,gic-v3";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- #interrupt-cells = <3>;
- interrupt-controller;
- reg = <0x00 0x0180 0x00 0x1>, /* GICD */
- <0x00 0x0184 0x00 0xC>, /* GICR */
- <0x01 0x 0x00 0x2000>,/* GICC */
-
Re: [PATCH v3 00/13] Hello Again Everyone!
On Mon, Feb 26, 2024 at 03:19:06PM -0600, Bryan Brattlof wrote: > **Note:** This series depends on the v6 OF_UPSTREAM work from Sumit[0]. > Patch #11 was added to fix some Makefile.spl targets to allow SPL builds > to complete with the OF_UPSTREAM series. > > The AM62Px is an extension of the existing Sitara AM62x low-cost family > of application processors built for Automotive and Linux Application > development. Scalable Arm Cortex-A53 performance and embedded features, > such as: multi high-definition display support, 3D-graphics > acceleration, 4K video acceleration, and extensive peripherals make the > AM62Px well-suited for a broad range of automation and industrial > application, including automotive digital instrumentation, automotive > displays, industrial HMI, and more. > > Some highlights of AM62P SoC are: > > * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. > Dual/Single core variants are provided in the same package to allow HW > compatible designs. > > * One Device manager Cortex-R5F for system power and resource > management, and one Cortex-R5F for Functional Safety or > general-purpose usage. > > * One 3D GPU up to 50 GLFOPS > > * H.264/H.265 Video Encode/Decode. > > * Display support: 3x display support over OLDI/LVDS (1x OLDI-DL, 1x or > 2x OLDI-SL), DSI, or DPI. Up to 3840x1080 @ 60fps resolution > > * Integrated Giga-bit Ethernet switch supporting up to a total of two > external ports (TSN capable). > > * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3xMMC and SD, GPMC for > NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio, > 1xCSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals. > > * Dedicated Centralized Hardware Security Module with support for secure > boot, debug security and crypto acceleration and trusted execution > environment. > > * One 32-bit DDR Subsystem that supports LPDDR4, DDR4 memory types. > > * Multiple low power modes support, ex: Deep sleep, Standby, MCU-only, > enabling battery powered system design. > > For those interested, more details about this SoC can be found in the > Technical Reference Manual here: https://www.ti.com/lit/pdf/spruj83 > > Proof-of-Life: > https://paste.sr.ht/~bryanb/af2ac108a9362549aa326f182e87918d52bf2d71 > > Currently, while more peripherals are being added in Linux[0], this > series will only support UART boot. Please rebase this on top of current -next, there's conflicts with other TI patches I've merged now, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arch/arm/mach-omap2/omap5/fdt.c: ft_fixup_clocks: use clock-output-names property as fallback (kernel 5.19+)
On Mon, 22 Jan 2024 11:30:44 +0100, Romain Naour wrote: > Clock names has been updated in kernel 5.19+ with the removal of > non-standard node names [1]. Due to this change, ft_opp_clock_fixups() > doesn't work anymore since ft_fixup_clocks() is looking to the clock > name and ft_opp_clock_fixups() error out with the following message: > > ft_fixup_clocks failed for DSP voltage domain: > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v2 0/3] Enable OSPI on j721e
On Fri, 23 Feb 2024 18:23:04 -0600, Jonathan Humphreys wrote:
> This series enables OSPI storage and boot.
>
> fixes: 58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts
> support")
>
> Changes from v1:
> - added patch to remove the OSPI phy pattern partition, as it wasn't used
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
Re: [PATCH V2] arm: dts: k3-binman: Make optee optional as requirement
On Mon, 26 Feb 2024 08:14:15 +0100, Michael Trimarchi wrote: > Allow boards that use ti_spl_template to not use optee part in > configuration. > Vendor can have module with 256 Mb of memory and they try to optimize > the available memory just using the essential components. > This change allow to remove tee from configuration without binman > fail. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v2 0/2] enable OSPI support on AM64x
On Fri, 23 Feb 2024 18:17:00 -0600, Jonathan Humphreys wrote:
> This series enables OSPI support for AM64x by setting the proper configs, and
> DT
> entries for SPL.
>
> fixes: fa09b12dc5f6 ("arm: ti: k3: Resync dts files and bindings with Linux
> Kernel v5.14")
>
> Changes from v1:
> - removed the OSPI phy pattern partition, as it wasn't used
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
Re: [PATCH] virtio: fix get_config / set_config for legacy VirtIO targets
On Mon, 12 Feb 2024 09:37:08 +0200, Dmitry Baryshkov wrote: > The functions virtio_pci_get_config() and virtio_pci_set_config() don't > take the offset into account when reading the config space. For example > this manifests when U-Boot tries to read the MAC address of the VirtIO > networking device. It reads 6 equa bytes instead of the proper addess. > > Fix those functions by taking the offset in the config space into > account. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On Tue Mar 5, 2024 at 4:37 PM CET, Marek Vasut wrote:
> On 3/5/24 1:50 PM, Michael Walle wrote:
> > Hi Marek,
>
> Hi,
>
> > On Tue Mar 5, 2024 at 1:31 PM CET, Marek Vasut wrote:
> >> On 3/5/24 9:55 AM, Michael Walle wrote:
> >>> On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote:
> Some Winbond SPI NORs have special SR3 register which is
> used among other things to control whether non-standard
> "Individual Block/Sector Write Protection" (WPS bit)
> locking scheme is activated. This non-standard locking
> scheme is not supported by either U-Boot or Linux SPI
> NOR stack so make sure it is disabled, otherwise the
> SPI NOR may appear locked for no obvious reason.
> >>>
> >>> I don't think it is a good idea to just disable the WPS bit.
> >>> Usually, that bit is non-volatile and the default is not set.
> >>
> >> Yes, that's right, the bit is non-volatile and should not be set unless
> >> the MTD stack can handle it correctly. Currently, neither U-Boot nor
> >> Linux does handle the bit at all, instead both attempt to use the
> >> standard SPI NOR locking scheme which is also implemented by this SPI
> >> NOR model and they both fail to unlock the SPI NOR that way.
> >>
> >> Note that the SR3 WPS bit only switches between two different locking
> >> schemes (unset = standard SPI NOR locking scheme, set = custom winbond
> >> locking scheme), setting SR3 WPS does not immediately imply the SPI NOR
> >> is locked, rather the opposite. Out of manufacturing, the SPI NOR is
> >> unlocked in either locking scheme. Depending on the SR3 WPS bit state,
> >> different commands are used to lock and unlock the SPI NOR.
> >>
> >> I recently ran across a device which had the SR3 WPS bit incorrectly set
> >> out of manufacturing of that device (i.e. before it was populated on a
> >> board at board manufacturer) and the device was locked using the custom
> >> locking scheme. I was not able to unlock or use that device because both
> >> U-Boot and Linux tried to use the standard scheme for that purpose.
> >
> > Still, I don't think it makes any sense, to disable that bit for all
> > winbond flashes just because there was one vendor which set it the
> > wrong way - or the board manufacturer didn't test it and programmed
> > the flash correctly.
>
> OK
>
> >> Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in
> >> Linux, since Linux that is booted afterward then gets a device that has
> >> locking scheme configured in a way that Linux expects and can operate.
> >>
> >> Better yet, if some old LTS version of the Linux kernel is in use, it
> >> will also work correctly, because this patch will configure the SPI NOR
> >> locking scheme to what Linux expects it to be, before the SPI NOR is
> >> handed over to that old kernel.
> >
> > Agreed, but it should *not* be done automatically and nor
> > unconditionally. Please don't just overwrite any locking bits just
> > because there is one flash which have it set.
>
> The unlock code is not triggered unconditionally, it is protected by
>
> if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)...
>
> Kconfig option, so this can be turned on/off in board config already.
Ahh, OK then :)
But keep in mind that enabling this option is foobar and I've gone
lengths to eliminate it in linux. And actually made that option in
u-boot.
See linux commit 31ad3eff093c ("mtd: spi-nor: keep lock bits if they
are non-volatile").
-michael
> > This should be either be a board level option or maybe expose some
> > command line interface to let the user change the settings.
> >
> >>> Thus,
> >>> there is likely someone, probably the manufacturer of the board,
> >>> who intentionally set this bit. Now, with this patch it will get
> >>> disabled *unconditionally*, forever.
> >>
> >> In my case, it is exactly the opposite, the SR3 WPS shouldn't have been
> >> set and the device should not have been locked, but it was and that
> >> confused both U-Boot and Linux.
> >>
> >> I would argue that if the board manufacturer intention was to lock the
> >> SPI NOR, they would have had multiple better options at their disposal,
> >> and those options should have been aligned with the software support:
> >> - nWP pin of the SPI NOR could be tied low to enable WRITE PROTECT
> >> - OTP bits could have been programmed to enable permanent WRITE PROTECT
> >> - standard SPI NOR locking scheme could have been used too
> >>
> >> If they did set SR3 WPS and hoped that U-Boot or Linux would fail to
> >> unlock the SPI NOR using standard locking scheme commands, that is I
> >> think broken design.
> >
> > There might be software/OS which could handle that correctly. Also,
> > if linux will ever learn to use the new locking scheme
> > unconditionally, u-boot will always mess it up then.
>
> See CONFIG_SPI_FLASH_UNLOCK_ALL above.
signature.asc
Description: PGP signature
Re: [PATCH] arm64: zynqmp: Do not describe u-boot.itb if SPL is disabled
On Fri, Feb 23, 2024 at 05:18:42PM +0100, Michal Simek wrote:
> There is no reason to describe u-boot.itb on system without SPL. Pretty
> much this is cover all systems which are using only boot.bin which contains
> all images inside.
>
> Signed-off-by: Michal Simek
> ---
>
> board/xilinx/common/board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> index 9641ed307b75..4f38b7d27684 100644
> --- a/board/xilinx/common/board.c
> +++ b/board/xilinx/common/board.c
> @@ -43,7 +43,7 @@ struct efi_fw_image fw_images[] = {
> .image_index = 1,
> },
> #endif
> -#if defined(XILINX_UBOOT_IMAGE_GUID)
> +#if defined(XILINX_UBOOT_IMAGE_GUID) &&
> defined(CONFIG_SPL_FS_LOAD_PAYLOAD_NAME)
What happens if this is defined with CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" ?
Cheers
/Ilias
> {
> .image_type_id = XILINX_UBOOT_IMAGE_GUID,
> .fw_name = u"XILINX-UBOOT",
> --
> 2.36.1
>
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On 3/5/24 1:50 PM, Michael Walle wrote: Hi Marek, Hi, On Tue Mar 5, 2024 at 1:31 PM CET, Marek Vasut wrote: On 3/5/24 9:55 AM, Michael Walle wrote: On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote: Some Winbond SPI NORs have special SR3 register which is used among other things to control whether non-standard "Individual Block/Sector Write Protection" (WPS bit) locking scheme is activated. This non-standard locking scheme is not supported by either U-Boot or Linux SPI NOR stack so make sure it is disabled, otherwise the SPI NOR may appear locked for no obvious reason. I don't think it is a good idea to just disable the WPS bit. Usually, that bit is non-volatile and the default is not set. Yes, that's right, the bit is non-volatile and should not be set unless the MTD stack can handle it correctly. Currently, neither U-Boot nor Linux does handle the bit at all, instead both attempt to use the standard SPI NOR locking scheme which is also implemented by this SPI NOR model and they both fail to unlock the SPI NOR that way. Note that the SR3 WPS bit only switches between two different locking schemes (unset = standard SPI NOR locking scheme, set = custom winbond locking scheme), setting SR3 WPS does not immediately imply the SPI NOR is locked, rather the opposite. Out of manufacturing, the SPI NOR is unlocked in either locking scheme. Depending on the SR3 WPS bit state, different commands are used to lock and unlock the SPI NOR. I recently ran across a device which had the SR3 WPS bit incorrectly set out of manufacturing of that device (i.e. before it was populated on a board at board manufacturer) and the device was locked using the custom locking scheme. I was not able to unlock or use that device because both U-Boot and Linux tried to use the standard scheme for that purpose. Still, I don't think it makes any sense, to disable that bit for all winbond flashes just because there was one vendor which set it the wrong way - or the board manufacturer didn't test it and programmed the flash correctly. OK Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in Linux, since Linux that is booted afterward then gets a device that has locking scheme configured in a way that Linux expects and can operate. Better yet, if some old LTS version of the Linux kernel is in use, it will also work correctly, because this patch will configure the SPI NOR locking scheme to what Linux expects it to be, before the SPI NOR is handed over to that old kernel. Agreed, but it should *not* be done automatically and nor unconditionally. Please don't just overwrite any locking bits just because there is one flash which have it set. The unlock code is not triggered unconditionally, it is protected by if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL)... Kconfig option, so this can be turned on/off in board config already. This should be either be a board level option or maybe expose some command line interface to let the user change the settings. Thus, there is likely someone, probably the manufacturer of the board, who intentionally set this bit. Now, with this patch it will get disabled *unconditionally*, forever. In my case, it is exactly the opposite, the SR3 WPS shouldn't have been set and the device should not have been locked, but it was and that confused both U-Boot and Linux. I would argue that if the board manufacturer intention was to lock the SPI NOR, they would have had multiple better options at their disposal, and those options should have been aligned with the software support: - nWP pin of the SPI NOR could be tied low to enable WRITE PROTECT - OTP bits could have been programmed to enable permanent WRITE PROTECT - standard SPI NOR locking scheme could have been used too If they did set SR3 WPS and hoped that U-Boot or Linux would fail to unlock the SPI NOR using standard locking scheme commands, that is I think broken design. There might be software/OS which could handle that correctly. Also, if linux will ever learn to use the new locking scheme unconditionally, u-boot will always mess it up then. See CONFIG_SPI_FLASH_UNLOCK_ALL above.
[PATCH 2/2] sandbox: select CONFIG_64BIT for X86_64
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to static analysis tools. Signed-off-by: Dan Carpenter --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 99e59d94c606..fb7772936cd5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -44,6 +44,7 @@ endchoice config X86_64 bool + select 64BIT config SPL_X86_64 bool -- 2.43.0
[PATCH 1/2] sandbox: select CONFIG_64BIT for SANDBOX64
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to static analysis tools. Signed-off-by: Dan Carpenter --- arch/sandbox/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig index 0ce77de2fcb4..c431da60e8c4 100644 --- a/arch/sandbox/Kconfig +++ b/arch/sandbox/Kconfig @@ -12,6 +12,7 @@ config SYS_CPU config SANDBOX64 bool "Use 64-bit addresses" + select 64BIT select PHYS_64BIT depends on HOST_64BIT -- 2.43.0
[PATCH 0/2] Select CONFIG_64BIT for sandbox64 and x86_64
I had previously set CONFIG_64BIT for arm64. This patchset does the same thing for sandbox64 and x86_64. (Mips and riscv were already doing it). This CONFIG option is used in the Makefile to determine if it's a 32 or 64 bit system for the CHECKER. Makefile 1052 # the checker needs the correct machine size 1053 CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32) Dan Carpenter (2): sandbox: select CONFIG_64BIT for SANDBOX64 sandbox: select CONFIG_64BIT for X86_64 arch/sandbox/Kconfig | 1 + arch/x86/Kconfig | 1 + 2 files changed, 2 insertions(+) -- 2.43.0
Re: [PATCH v2] initcall: break loop immediately on failure
On Tue, Mar 05, 2024 at 02:55:13PM +, Caleb Connolly wrote: > The current ordering always results in func pointing to the next > function in the init_sequence. e.g. if fdtdec_setup() fails, ret will > be set to the error code, then func will be updated to point to > initf_malloc(), only then is ret checked and the loop broken. The end > result of this is that the "initcall failed at ..." error will point you > to initf_malloc(), when the error actually occured in fdtdec_setup()! > > This can be quite confusing and result in a lot of time wasted debugging > code that has nothing to do with the failure (ask me how I know :P). > > Adjust the for loop to check ret immediately after the call and break > early so that func will correctly reference the failed function. > > Signed-off-by: Caleb Connolly > --- > Changes in v2: > - Don't drop the initialisation of ret (thanks Dan!). > - Link to v1: > https://lore.kernel.org/u-boot/20240219183519.2183405-1-caleb.conno...@linaro.org/ > > Cc: Dan Carpenter Awesome. Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter
[PATCH v2] initcall: break loop immediately on failure
The current ordering always results in func pointing to the next
function in the init_sequence. e.g. if fdtdec_setup() fails, ret will
be set to the error code, then func will be updated to point to
initf_malloc(), only then is ret checked and the loop broken. The end
result of this is that the "initcall failed at ..." error will point you
to initf_malloc(), when the error actually occured in fdtdec_setup()!
This can be quite confusing and result in a lot of time wasted debugging
code that has nothing to do with the failure (ask me how I know :P).
Adjust the for loop to check ret immediately after the call and break
early so that func will correctly reference the failed function.
Signed-off-by: Caleb Connolly
---
Changes in v2:
- Don't drop the initialisation of ret (thanks Dan!).
- Link to v1:
https://lore.kernel.org/u-boot/20240219183519.2183405-1-caleb.conno...@linaro.org/
Cc: Dan Carpenter
---
lib/initcall.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/initcall.c b/lib/initcall.c
index ce317af213ab..c8e2b0f6a386 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -54,9 +54,9 @@ int initcall_run_list(const init_fnc_t init_sequence[])
enum event_t type;
init_fnc_t func;
int ret = 0;
- for (ptr = init_sequence; func = *ptr, !ret && func; ptr++) {
+ for (ptr = init_sequence; func = *ptr, func; ptr++) {
type = initcall_is_event(func);
if (type) {
if (!CONFIG_IS_ENABLED(EVENT))
@@ -70,8 +70,10 @@ int initcall_run_list(const init_fnc_t init_sequence[])
debug("initcall: %p\n", (char *)func - reloc_ofs);
}
ret = type ? event_notify_null(type) : func();
+ if (ret)
+ break;
}
if (ret) {
if (CONFIG_IS_ENABLED(EVENT)) {
--
2.44.0
[PATCH v2] test: dm: add button_cmd test
Add a test for the button_cmd feature. This validates that commands can
be mapped to two buttons, that the correct command runs based on which
button is pressed, that only 1 command is run, and that no command runs
if button_cmd_0_name is wrong or unset.
Additionally, fix a potential uninitialised variable use caught by these
tests, the btn variable in get_button_cmd() is assumed to be null if
button_get_by_label() fails, but it's actually used uninitialised in
that case.
CONFIG_BUTTON is now enabled automatically and was removed when running
save_defconfig.
Signed-off-by: Caleb Connolly
Fixes: e761035b6423 ("boot: add support for button commands")
---
Changes in v2:
- Explicitly assign btn as NULL in get_button_cmd(). This fixes a
bug where if the undefined variable is non-zero the
button_get_by_label() check would fail and result in invalid memory
being accessed.
- Enable CONFIG_BUTTON_CMD for sandbox64 as well as sandbox.
- Link to v1:
https://lore.kernel.org/u-boot/20240214170357.4091708-1-caleb.conno...@linaro.org/
---
common/button_cmd.c | 2 +-
configs/sandbox64_defconfig | 2 +-
configs/sandbox_defconfig | 2 +-
test/dm/button.c| 96 +
4 files changed, 99 insertions(+), 3 deletions(-)
diff --git a/common/button_cmd.c b/common/button_cmd.c
index b6a8434d6f29..8642c26735cc 100644
--- a/common/button_cmd.c
+++ b/common/button_cmd.c
@@ -32,9 +32,9 @@ struct button_cmd {
*/
static int get_button_cmd(int n, struct button_cmd *cmd)
{
const char *cmd_str;
- struct udevice *btn;
+ struct udevice *btn = NULL;
char buf[24];
snprintf(buf, sizeof(buf), "button_cmd_%d_name", n);
cmd->btn_name = env_get(buf);
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index d101cca6a738..a62faf772482 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -10,8 +10,9 @@ CONFIG_PCI=y
CONFIG_SANDBOX64=y
CONFIG_DEBUG_UART=y
CONFIG_SYS_MEMTEST_START=0x0010
CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_LEGACY_IMAGE_FORMAT=y
@@ -122,9 +123,8 @@ CONFIG_SYS_ATA_STRIDE=4
CONFIG_SYS_ATA_DATA_OFFSET=0
CONFIG_SYS_ATA_REG_OFFSET=1
CONFIG_SYS_ATA_ALT_OFFSET=2
CONFIG_SYS_ATA_IDE0_OFFSET=0
-CONFIG_BUTTON=y
CONFIG_BUTTON_ADC=y
CONFIG_BUTTON_GPIO=y
CONFIG_CLK=y
CONFIG_CLK_COMPOSITE_CCF=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index a8df5e635b26..93b52f2de5cf 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -9,8 +9,9 @@ CONFIG_SYS_LOAD_ADDR=0x0
CONFIG_PCI=y
CONFIG_DEBUG_UART=y
CONFIG_SYS_MEMTEST_START=0x0010
CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
CONFIG_FIT_VERBOSE=y
@@ -165,9 +166,8 @@ CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_DM_BOOTCOUNT=y
CONFIG_DM_BOOTCOUNT_RTC=y
CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
CONFIG_DM_BOOTCOUNT_SYSCON=y
-CONFIG_BUTTON=y
CONFIG_BUTTON_ADC=y
CONFIG_BUTTON_GPIO=y
CONFIG_CLK=y
CONFIG_CLK_COMPOSITE_CCF=y
diff --git a/test/dm/button.c b/test/dm/button.c
index 3318668df25a..830d96fbef34 100644
--- a/test/dm/button.c
+++ b/test/dm/button.c
@@ -130,4 +130,100 @@ static int dm_test_button_keys_adc(struct unit_test_state
*uts)
return 0;
}
DM_TEST(dm_test_button_keys_adc, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test of the button uclass using the button_gpio driver */
+static int dm_test_button_cmd(struct unit_test_state *uts)
+{
+ struct udevice *btn1_dev, *btn2_dev, *gpio;
+ const char *envstr;
+
+#define BTN1_GPIO 3
+#define BTN2_GPIO 4
+#define BTN1_PASS_VAR "test_button_cmds_0"
+#define BTN2_PASS_VAR "test_button_cmds_1"
+
+ /*
+* Buttons 1 and 2 are connected to gpio_a gpios 3 and 4 respectively.
+* set the GPIOs to known values and then check that the appropriate
+* commands are run when invoking process_button_cmds().
+*/
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 1, _dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 2, _dev));
+ ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
+
+ /*
+* Map a command to button 1 and check that it process_button_cmds()
+* runs it if called with button 1 pressed.
+*/
+ ut_assertok(env_set("button_cmd_0_name", "button1"));
+ ut_assertok(env_set("button_cmd_0", "env set " BTN1_PASS_VAR " PASS"));
+ ut_assertok(sandbox_gpio_set_value(gpio, BTN1_GPIO, 1));
+ /* Sanity check that the button is actually pressed */
+ ut_asserteq(BUTTON_ON, button_get_state(btn1_dev));
+ process_button_cmds();
+ ut_assertnonnull((envstr = env_get(BTN1_PASS_VAR)));
+ ut_asserteq_str(envstr, "PASS");
+
+ /* Clear result */
+ ut_assertok(env_set(BTN1_PASS_VAR, NULL));
+
+ /*
+* Map a command for button 2, press it, check that
Re: [PATCH] configs: rockchip: rock5b: enable environment
On 2024-03-05 11:11, Quentin Schulz wrote: > Hi all, > > On 3/5/24 10:36, Christopher Obbard wrote: >> [You don't often get email from chris.obb...@collabora.com. Learn why this >> is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Hi Jonas & Trevor, >> >> On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote: >>> Hi Trevor, >>> >>> On 2024-03-05 03:10, Trevor Woerner wrote: Following the pattern of other Rockchip devices, enable the U-Boot environment to be stored in MMC. This patch specifically assumes the environment will be stored on the SDcard. >>> >>> This board has SPI flash, so storing env in SPI flash is probably a >>> better default. >> >> I agree with that. >> >>> However, preferably the env should be stored/loaded from >>> the same device that TPL/SPL was loaded from. >> >> Do you know if there is some mechanism in U-Boot to do this already ? >> > > We do this for our Theobroma boards, though we use the same device that > U-Boot proper was loaded from, and not the one that TPL+SPL was loaded > from but the logic could be more or less the same. Good catch, same as U-Boot proper may be more accurate and what I was expecting, I typically expect TPL+SPL and FIT to be loaded from same media so may see them as interchangeably. My normal expectation will be that if FIT cannot be loaded from same-as-spl we are in some kind of fallback and/or recovery mode. Maybe a u-boot,env-load-order prop, similar to u-boot,spl-boot-order, could be an option? with support for similar options, same-as-spl and same-as-fit/proper/boot or node refs. > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L92-L152 > > is what you need. The first function is to differentiate between SD card > and eMMC, the second actually returns the **kind** of medium the > environment is stored on (so MMC or SPI-flash for Theobroma boards). > > Instead of > https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L94-L95 > > you probably want to use board_spl_was_booted_from(). > > Note that to you need the MMC and SPI controllers to be bound in U-Boot > proper **before relocation** for this to work. c.f. > https://lore.kernel.org/u-boot/20240221-jaguar-v3-15-1f256a822...@theobroma-systems.com/ > >> It could be useful to enable autodetection on many boards which can boot U- >> Boot from either SPI flash / eMMC / SD card. >> > > There's been an attempt recently: > > https://lore.kernel.org/u-boot/20240226011413.435713-2-benwolsief...@gmail.com/ > > though only for the MMC part of the equation. I thought I noticed something related last few days/weeks, did not manage to find anything when I went looking for it :-) Regards, Jonas > > Cheers, > Quentin
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
[trimmed CC list a bit as this is getting offtopic for the original thread]
On 05/03/2024 13:14, Sumit Garg wrote:
> On Tue, 5 Mar 2024 at 18:21, Caleb Connolly wrote:
>>
>>
>>
>> On 05/03/2024 12:35, Sumit Garg wrote:
>>> Hi Caleb,
>>>
>>> On Mon, 4 Mar 2024 at 22:22, Caleb Connolly
>>> wrote:
This adjusts OF_UPSTREAM to behave more like the kernel by allowing for
all the devicetree files for a given vendor to be compiled. This is
useful for Qualcomm in particular as most boards are supported by a
single U-Boot build just provided with a different DT.
Signed-off-by: Caleb Connolly
---
dts/Kconfig | 24
scripts/Makefile.dts | 17 -
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/dts/Kconfig b/dts/Kconfig
index b9b6367154ef..67d9dc489856 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -100,8 +100,32 @@ config OF_UPSTREAM
However, newer boards whose devicetree source files haven't
landed in
the dts/upstream subtree, they can override this option to have
the
DT build from existing U-Boot tree location instead.
+config OF_UPSTREAM_BUILD_VENDOR
+ bool "Build all devicetree files for a particular vendor"
+ depends on OF_UPSTREAM
+ help
+ Enable building all devicetree files for a particular vendor.
This
>>>
>>> Do we really want to build all the DTBs even if many of those aren't
>>> supported by U-Boot at all? I would have rather added Makefile targets
>>> for boards which really supports a single defconfig eg.
>>> qcom_defconfig.
>>
>> Yes, for the 4 Qualcomm SoCs currently supported there are 51 dts
>> targets that ought to be able to run U-Boot to some extent
>
> Have you tested U-Boot on all of them? IMO, it would be good to make
> people aware about supported boards via listing their DTs at least.
Well the "ideal" goal is that every SoC in upstream is supported. All of
the changes I've introduced so far work towards that end, so this is
just another step in that direction. Obviously it's a lofty one, but I
see no reason to intentionally make things harder for ourselves by
gatekeeping what DTB files we build.
I have additional features planned that help here, and plenty more
ideas... But I can confirm that most of the phones (which are pretty
much identical to the reference boards) do indeed "just work" provided
the SoC is supported.
It makes sense to use board/qualcomm//MAINTAINERS for this
imo, there we can reference the specific dts files so device maintainers
can be CC'd if there are relevant changes when deviceree-rebasing is
updated.
I would like to update the Qualcomm docs to describe the general
approach here and help guide new contributors. But (as is hopefully
obvious by this email) I'm still very much learning as I go. What do you
think?
>
>>
>> $ ls -l dts/upstream/src/arm6/qcom/{msm8916,sdm845,msm8996,qcs404}*.dts\
>> | wc -l
>> 51
>>
>
> qcom_defconfig currently only supports sdm845 and qcs404.
>
>> What do you mean by a "makefile target"? Like copying
>> arch/arm64/boot/dts/qcom/Makefile from Linux? I guess my concern here
>> would be keeping it in sync, and introducing additional busywork when
>> porting.
>
> See following diff:
>
> diff --git a/dts/upstream/src/arm64/Makefile b/dts/upstream/src/arm64/Makefile
> index 9a8f6aa35846..ecc15021cb08 100644
> --- a/dts/upstream/src/arm64/Makefile
> +++ b/dts/upstream/src/arm64/Makefile
> @@ -2,6 +2,10 @@
>
> include $(srctree)/scripts/Makefile.dts
>
> +dtb-$(CONFIG_ARCH_SNAPDRAGON) += qcom/sdm845-db845c.dtb \
> + qcom/sdm845-samsung-starqltechn.dtb \
> + qcom/qcs404-evb-4000.dtb
> +
> targets += $(dtb-y)
>
>>
>> We do have a lot of Qualcomm DTS files, it takes maybe 10 seconds to
>> compile them all on my machine, but that's only once. With incremental
>> builds this becomes largely irrelevant.
>
> Maybe someone cares about build time too but that's not my primary
> concern. We shouldn't be giving the false impression that all the DTs
> present in the vendor directory are supported by U-Boot.
>
> -Sumit
--
// Caleb (they/them)
Re: [PATCH v2 5/8] phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
On Tue, Mar 5, 2024 at 7:48 AM Sumit Garg wrote:
>
> Hi Adam,
>
> On Wed, 28 Feb 2024 at 12:29, Sumit Garg wrote:
> >
> > Hi Adam,
> >
> > On Wed, 28 Feb 2024 at 04:42, Adam Ford wrote:
> > >
> > > On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg wrote:
> > > >
> > > > Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs PCIe
> > > > PHY initialization moved to this standalone PHY driver.
> > > >
> > > > Inspired from counterpart Linux kernel v6.8-rc3 driver:
> > > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c.
> > >
> > > I have a PCIe device that works just fine in Linux. I have applied
> > > your series an enabled the same config options as you did along with
> > > some others to resolve some build issues.
> > >
> > > Any ideas how to address:
> > >
> > > nxp_imx8_pcie_phy pcie-phy@32f0: PHY: Failed to power on
> > > pcie-phy@32f0: -110.
> > >
> > > My PHY node looks like this
> > >
> > > _phy {
> > > fsl,refclk-pad-mode = ;
> > > clocks = <_refclk>;
> > > clock-names = "ref";
> > > status = "okay";
> > > };
> > >
> > > The pcie_refcllk is defined as a 100MHz fixed clock in U-Boot. clk
> > > dump shows it to be:
> > >
> > > 10|-- clock-pcie
> > >
> >
> > I suppose that's an EVK board, try enabling MPCIE_3V3 regulator
> > required for EVK board via following patch:
> >
> > diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> > index 7856823c9188..32fd2cb05d4b 100644
> > --- a/drivers/pci/pcie_dw_imx.c
> > +++ b/drivers/pci/pcie_dw_imx.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -158,6 +159,8 @@ static int pcie_dw_imx_probe(struct udevice *dev)
> > struct pci_controller *hose = dev_get_uclass_priv(ctlr);
> > int ret;
> >
> > + regulator_autoset_by_name("MPCIE_3V3", NULL);
> > +
> > ret = imx_pcie_assert_core_reset(priv);
> > if (ret) {
> > dev_err(dev, "failed to assert core reset\n");
> >
>
> Were you able to give a retry with the above diff?
Not yet, but I'll try to do it tonight.
adam
>
> -Sumit
Re: [PATCH v2 5/8] phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
Hi Adam,
On Wed, 28 Feb 2024 at 12:29, Sumit Garg wrote:
>
> Hi Adam,
>
> On Wed, 28 Feb 2024 at 04:42, Adam Ford wrote:
> >
> > On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg wrote:
> > >
> > > Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs PCIe
> > > PHY initialization moved to this standalone PHY driver.
> > >
> > > Inspired from counterpart Linux kernel v6.8-rc3 driver:
> > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c.
> >
> > I have a PCIe device that works just fine in Linux. I have applied
> > your series an enabled the same config options as you did along with
> > some others to resolve some build issues.
> >
> > Any ideas how to address:
> >
> > nxp_imx8_pcie_phy pcie-phy@32f0: PHY: Failed to power on
> > pcie-phy@32f0: -110.
> >
> > My PHY node looks like this
> >
> > _phy {
> > fsl,refclk-pad-mode = ;
> > clocks = <_refclk>;
> > clock-names = "ref";
> > status = "okay";
> > };
> >
> > The pcie_refcllk is defined as a 100MHz fixed clock in U-Boot. clk
> > dump shows it to be:
> >
> > 10|-- clock-pcie
> >
>
> I suppose that's an EVK board, try enabling MPCIE_3V3 regulator
> required for EVK board via following patch:
>
> diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> index 7856823c9188..32fd2cb05d4b 100644
> --- a/drivers/pci/pcie_dw_imx.c
> +++ b/drivers/pci/pcie_dw_imx.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -158,6 +159,8 @@ static int pcie_dw_imx_probe(struct udevice *dev)
> struct pci_controller *hose = dev_get_uclass_priv(ctlr);
> int ret;
>
> + regulator_autoset_by_name("MPCIE_3V3", NULL);
> +
> ret = imx_pcie_assert_core_reset(priv);
> if (ret) {
> dev_err(dev, "failed to assert core reset\n");
>
Were you able to give a retry with the above diff?
-Sumit
Re: [PATCH] qcom_defconfig: Enable ethernet and I2C support
On Mon, 19 Feb 2024 at 14:11, Sumit Garg wrote: > > QCS404 supports Synopsys Designware Ethernet QOS IP and we already have > the corresponding glue layer present upstream as: > drivers/net/dwc_eth_qos_qcom.c. So enable corresponding support. > > Along with that it is possible for Qualcomm platforms to retrieve MAC > address from I2C eeprom present on board. So enable corresponding > support as well. > > Signed-off-by: Sumit Garg > --- > > This patch based upon Caleb's series [1]. > > [1] > https://lore.kernel.org/all/20240215-b4-qcom-common-target-v4-0-ed06355c6...@linaro.org/ > Gentle ping. -Sumit > configs/qcom_defconfig | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig > index 222db6448aba..cbc612b44bd9 100644 > --- a/configs/qcom_defconfig > +++ b/configs/qcom_defconfig > @@ -26,7 +26,6 @@ CONFIG_CMD_USB=y > CONFIG_CMD_CAT=y > CONFIG_CMD_BMP=y > CONFIG_CMD_LOG=y > -# CONFIG_NET is not set > CONFIG_BUTTON_QCOM_PMIC=y > CONFIG_CLK=y > CONFIG_CLK_QCOM_QCS404=y > @@ -65,3 +64,26 @@ CONFIG_VIDEO_SIMPLE=y > CONFIG_HEXDUMP=y > # CONFIG_GENERATE_SMBIOS_TABLE is not set > CONFIG_LMB_MAX_REGIONS=64 > +CONFIG_CMD_DHCP=y > +CONFIG_CMD_EEPROM=y > +CONFIG_CMD_I2C=y > +CONFIG_CMD_PING=y > +CONFIG_DM_ETH=y > +CONFIG_DM_ETH_PHY=y > +CONFIG_DM_MDIO=y > +CONFIG_DWC_ETH_QOS=y > +CONFIG_DWC_ETH_QOS_QCOM=y > +CONFIG_RGMII=y > +CONFIG_PHY_MICREL=y > +CONFIG_PHY_MICREL_KSZ90X1=y > +CONFIG_MISC=y > +CONFIG_NVMEM=y > +CONFIG_DM_I2C=y > +CONFIG_I2C_SUPPORT=y > +CONFIG_I2C_MUX=y > +CONFIG_I2C_EEPROM=y > +CONFIG_SYS_I2C=y > +CONFIG_SYS_I2C_QUP=y > +CONFIG_SYS_I2C_EEPROM_BUS=2 > +CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5 > -- > 2.34.1 >
Re: [PATCH] configs: rockchip: rock5a: enable environment
On Tue 2024-03-05 @ 10:17:10 AM, Jonas Karlman wrote: > Hi, > > On 2024-03-05 06:40, Eugen Hristev wrote: > > On 3/5/24 04:10, Trevor Woerner wrote: > >> Following the pattern of other Rockchip devices, enable the U-Boot > >> environment to be stored in MMC. This patch specifically assumes the > >> environment will be stored on the SDcard. > >> > >> Signed-off-by: Trevor Woerner > >> --- > >> configs/rock5a-rk3588s_defconfig | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/configs/rock5a-rk3588s_defconfig > >> b/configs/rock5a-rk3588s_defconfig > >> index a6471a519514..ac6411667d9a 100644 > >> --- a/configs/rock5a-rk3588s_defconfig > >> +++ b/configs/rock5a-rk3588s_defconfig > >> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y > >> CONFIG_NR_DRAM_BANKS=2 > >> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > >> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0 > >> +CONFIG_ENV_SIZE=0x8000 > >> CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a" > >> CONFIG_ROCKCHIP_RK3588=y > >> CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y > >> @@ -48,6 +49,8 @@ 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_ENV_IS_IN_MMC=y > >> +CONFIG_SYS_MMC_ENV_DEV=1 > >> CONFIG_SPL_DM_SEQ_ALIAS=y > >> CONFIG_SPL_REGMAP=y > >> CONFIG_SPL_SYSCON=y > > > > > > Hi Trevor, > > > > What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash > > ? > > Agree, we should not blindly enable env and expect that it can be stored > on sd-card. If anything, it should preferably be saved/loaded from the > device where TPL/SPL was booted from. > > Personally I always run my devices with ENV_IS_NOWHERE, with standard > boot and extlinux or efi as the preferred way to boot, I do not see why > normal end-users with a single OS really have a need for a saved env, > please educate me :-) I am the maintainer of the meta-rockchip Yocto layer[1]. Yocto uses a nifty tool called 'wic' to layout images (dos/gpt partitioning, optionally formatting partitions, optionally installing things into those partitions)[2]. The partitioning layout that we follow is the one that is recommended by Rockchip itself[3] with 2 exceptions: - we don't hide any of the partitions from the partition table - we've combined /boot into the root partition (for reasons I'll explain later) Under the Rockchip partitioning, the U-Boot environment is stored in partition 5, at offset 0x0003.f800, and has a size of 0x.8000. I don't own every Rockchip board, but I have a bunch of them (thanks to some generous donations!). I've created a spreadsheet that lists the ones supported by meta-rockchip and their environment variable U-Boot configurations (locations, offsets, sizes). Most of them follow the Rockchip recommended partitioning layout with regards to storing the environment. This set of patches closes that gap, at least for the ones supported by meta-rockchip. One of the things that I want to do next with meta-rockchip is to provide an easy way for users to enable some sort of A/B OTA update strategy. Currently, enabling an A/B update mechanism for any board (Rockchip or not) is a non-trivial exercise. Every A/B update mechanism that I've looked at requires (among other things) the bootloader to be able to store/retrieve its environment from U-Boot itself (obviously) and also from Linux userspace since it is the bootloader that ultimately boots from either the A or the B partition. I'm specifically focused on rauc, but all the A/B update mechanisms I've looked at have this same requirement. Users who don't care for A/B updates can simply use meta-rockchip as-is, those who want an A/B strategy would simply enable a setting or two in their Yocto config and meta-rockchip would take care of the details, regardless of which Rockchip board they're using. I've combined /boot into the root partition since it makes A/B updates easier. Otherwise in order to work it would actually be an Aboot+Aroot/Bboot+Broot mechanism, which is clumsy. Also since U-Boot is stored in partition by itself, the only thing in the /boot partition is the U-Boot boot mechanism (boot script, extlinux, etc), the Linux kernel, and the DTB (or fitImage). In general it's better to keep the kernel and the root filesystem in sync, so having a separate /boot partition is clumsy for no gain. The other nice thing about wic is that it allows us to store random data (or filesystems) in the image as we're creating it for the first time. In other words, I have a mechanism that allows me to create the initial/default U-Boot environment during the build, I can add or remove variables from it dynamically as part of my build process, generate the proper binary blob of that environment (i.e. with checksum), and lay it out into partition 5 of the generated image so that on first boot the environment is already setup with whatever U-Boot needs
Re: [PATCH] configs: rockchip: rock5b: enable environment
Hello all, On 2024-03-05 10:36, Christopher Obbard wrote: On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote: On 2024-03-05 03:10, Trevor Woerner wrote: > Following the pattern of other Rockchip devices, enable the U-Boot > environment to be stored in MMC. This patch specifically assumes the > environment will be stored on the SDcard. This board has SPI flash, so storing env in SPI flash is probably a better default. I agree with that. However, preferably the env should be stored/loaded from the same device that TPL/SPL was loaded from. Do you know if there is some mechanism in U-Boot to do this already ? It could be useful to enable autodetection on many boards which can boot U- Boot from either SPI flash / eMMC / SD card. I agree that doing this on all Rockchip boards should be the way to go, or perhaps to use the device that the U-Boot proper was loaded from. Moreover, it would, for example, allow a microSD card to be used as a rescue boot media for the users to recover from a borked environment.
Re: [PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On Tue, Mar 05, 2024 at 02:39:14PM +0530, MD Danish Anwar wrote: > On 29/02/24 3:43 pm, Roger Quadros wrote: > > > > > > On 28/02/2024 14:06, MD Danish Anwar wrote: > >> Add APIs to set a firmware_name to a rproc and boot the rproc with the > >> same firmware. > >> > >> Clients can call rproc_set_firmware() API to set firmware_name for a rproc > >> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to > >> a buffer by calling request_firmware_into_buf(). rproc_boot() will then > >> load the firmware file to the remote processor and start the remote > >> processor. > >> > >> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in > >> Kconfig so that we can call request_firmware_into_buf() from remoteproc > >> driver. > >> > >> Signed-off-by: MD Danish Anwar > >> Acked-by: Ravi Gunasekaran > > > > Reviewed-by: Roger Quadros > > Hi Tom, > > Can you please pick this patch. There are no active comments on this > patch and Roger and Ravi has reviewed / acked the patch. Yes, I'm going to give people a little longer to comment / review and will pull this to -next soon. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/master
On Tue, Mar 05, 2024 at 11:35:30AM +0100, Stefan Roese wrote: > Hi Tom, > > please pull this next batch of mostly Marvell related patches: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-sunxi/master for v2024.04
On Tue, Mar 05, 2024 at 11:15:41AM +, Andre Przywara wrote: > Hi Tom, > > please pull the sunxi/master branch, containing some fixes and smaller > changes for 2024.04. > One fix makes the reboot more robust on some older board, another one > stabilises the initial clock setup on the A10/A20. > Two patches make sure our DRAM init does not actually change the content > of the DRAM array, which allows to use DRAM for Linux' pstore > functionality. > We get SPI support for U-Boot proper for one more SoC, that patch was > lingering around for a while, and should not affect other SoCs, so I am > merging this now. > As an added bonus, we get the defconfig file for a new board, the DT was > already synced from the kernel tree. > > The CI looked happy with changes, and I tested them on five different > boards with different SoCs. > > Please pull! > > Cheers, > Andre > > == > The following changes since commit eac52e4be4e234d563d6911737ee7ccdc0ada1f1: > > Merge patch series "ARM: renesas: Rename R-Mobile to Renesas" (2024-03-02 > 14:30:25 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master > > for you to fetch changes up to f1e6a718ebab0682d80601db404e8d842767becf: > > sunxi: restore modified memory (2024-03-05 01:16:56 +) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH not-for-merge 5/5] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO
Move GPIO pinmux to MDIO node. Add GB Ethernet reset GPIO.
Add PIN_INPUT to Fix SPE ethernet reset gpio so that
reading the GPIO can give correct status.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay.dts
b/arch/arm/dts/k3-am625-beagleplay.dts
index a34e0df2ab..8ab838f169 100644
--- a/arch/arm/dts/k3-am625-beagleplay.dts
+++ b/arch/arm/dts/k3-am625-beagleplay.dts
@@ -292,6 +292,8 @@
pinctrl-single,pins = <
AM62X_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AD24) MDIO0_MDC
*/
AM62X_IOPAD(0x015c, PIN_INPUT, 0) /* (AB22) MDIO0_MDIO
*/
+ AM62X_IOPAD(0x003c, PIN_INPUT, 7) /* (M25)
GPMC0_AD0.GPIO0_15 */
+ AM62X_IOPAD(0x018c, PIN_INPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
>;
};
@@ -383,7 +385,6 @@
AM62X_IOPAD(0x016c, PIN_INPUT, 1) /* (Y18)
RGMII2_TD0.RMII2_TXD0 */
AM62X_IOPAD(0x0170, PIN_INPUT, 1) /* (AA18)
RGMII2_TD1.RMII2_TXD1 */
AM62X_IOPAD(0x0164, PIN_INPUT, 1) /* (AA19)
RGMII2_TX_CTL.RMII2_TX_EN */
- AM62X_IOPAD(0x018c, PIN_OUTPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
AM62X_IOPAD(0x0190, PIN_INPUT, 7) /* (AE22)
RGMII2_RD3.GPIO1_6 */
AM62X_IOPAD(0x01f0, PIN_OUTPUT, 5) /* (A18)
EXT_REFCLK1.CLKOUT0 */
>;
@@ -597,6 +598,9 @@
cpsw3g_phy0: ethernet-phy@0 {
reg = <0>;
+ reset-gpios = <_gpio0 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <5>;
};
cpsw3g_phy1: ethernet-phy@1 {
@@ -615,7 +619,7 @@
"USR0", "USR1", "USR2", "USR3", "", "", "USR4", /* 3-9 */
"EEPROM_WP",/* 10 */
"CSI2_CAMERA_GPIO1", "CSI2_CAMERA_GPIO2", /* 11-12 */
- "CC1352P7_BOOT", "CC1352P7_RSTN", "", "", "", /* 13-17 */
+ "CC1352P7_BOOT", "CC1352P7_RSTN", "GBE_RSTN", "", "", /*
13-17 */
"USR_BUTTON", "", "", "", "", "", "", "", "", /* 18-26 */
"", "", "", "", "", "", "", "", "", "HDMI_INT", /* 27-36 */
"", "VDD_WLAN_EN", "", "", "WL_IRQ", "GBE_INTN",/* 37-42 */
--
2.34.1
[PATCH not-for-merge 4/5] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
Add missing bits to get CPSW Ethernet working.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index a723caa580..fc05121ccc 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -213,3 +213,66 @@
};
};
#endif
+
+_bcdma {
+ reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan";
+};
+
+_pktdma {
+ reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt", "cfg",
+ "tchan", "rchan", "rflow";
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+
+ ethernet-ports {
+ bootph-all;
+ };
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
+_port1 {
+ bootph-all;
+};
+
+_port2 {
+ status = "disabled";
+};
--
2.34.1
[PATCH not-for-merge 3/5] arm: dts: k3-am62*: sync with linux-next-20240229
Update k3-am62 DT files from linux-next-20240229.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am62-main.dtsi | 126 ++---
arch/arm/dts/k3-am62-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62-phycore-som.dtsi | 5 +-
arch/arm/dts/k3-am62-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62-verdin-dev.dtsi| 4 +-
arch/arm/dts/k3-am62-verdin-wifi.dtsi | 1 -
arch/arm/dts/k3-am62-verdin.dtsi| 76 ---
arch/arm/dts/k3-am62-wakeup.dtsi| 38 --
arch/arm/dts/k3-am62.dtsi | 4 +-
arch/arm/dts/k3-am625-beagleplay.dts| 58
arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +-
arch/arm/dts/k3-am625-sk.dts| 4 +-
arch/arm/dts/k3-am625.dtsi | 4 +-
arch/arm/dts/k3-am62a-main.dtsi | 201 ++--
arch/arm/dts/k3-am62a-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62a-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62a-wakeup.dtsi | 4 +-
arch/arm/dts/k3-am62a.dtsi | 4 +-
arch/arm/dts/k3-am62a7-sk.dts | 162 +-
arch/arm/dts/k3-am62a7.dtsi | 4 +-
arch/arm/dts/k3-am62x-sk-common.dtsi| 24 +++-
21 files changed, 714 insertions(+), 127 deletions(-)
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index e5c64c86d1..e9cffca073 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -1,8 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
/*
* Device Tree Source for AM625 SoC Family Main Domain peripherals
*
- * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
_main {
@@ -42,9 +42,8 @@
};
};
- main_conf: syscon@10 {
- compatible = "syscon", "simple-mfd";
- reg = <0x00 0x0010 0x00 0x2>;
+ main_conf: bus@10 {
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x00 0x0010 0x2>;
@@ -121,8 +120,13 @@
<0x00 0x4c00 0x00 0x2>,
<0x00 0x4a82 0x00 0x2>,
<0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
@@ -138,8 +142,13 @@
reg = <0x00 0x485c 0x00 0x100>,
<0x00 0x4a80 0x00 0x2>,
<0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x1>,
+ <0x00 0x484a 0x00 0x2000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x1000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
@@ -502,6 +511,9 @@
main_gpio0: gpio@60 {
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x0060 0x0 0x100>;
+ gpio-ranges = <_pmx0 0 0 32>,
+ <_pmx0 32 33 38>,
+ <_pmx0 70 72 22>;
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <_gpio_intr>;
@@ -520,6 +532,10 @@
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x00601000 0x0 0x100>;
gpio-controller;
+ gpio-ranges = <_pmx0 0 94 41>,
+ <_pmx0 41 136 6>,
+ <_pmx0 47 143 3>,
+ <_pmx0 50 149 2>;
#gpio-cells = <2>;
interrupt-parent = <_gpio_intr>;
[PATCH 2/5] configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
Reset GPIO handling is done in ETH PHY Class driver. Enable DM_ETH_PHY. We don't use Fixed PHY so disable PHY_FIXED. Signed-off-by: Roger Quadros --- configs/am62x_beagleplay_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am62x_beagleplay_a53_defconfig b/configs/am62x_beagleplay_a53_defconfig index 1f43891d10..a8925e4dcf 100644 --- a/configs/am62x_beagleplay_a53_defconfig +++ b/configs/am62x_beagleplay_a53_defconfig @@ -90,9 +90,9 @@ CONFIG_SPL_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_AM654=y CONFIG_PHY_REALTEK=y CONFIG_PHY_TI=y -CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PHY=y +CONFIG_DM_ETH_PHY=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_SINGLE=y -- 2.34.1
[PATCH 1/5] net: mdio-uclass: Bind and probe generic Ethernet PHY driver
If DM_ETH_PHY is enabled then try to bind and probe the
generic Ethernet PHY driver for each child of MDIO bus.
This is to ensure that GPIO reset handling is done if available
before MDIO bus driver scans for the PHYs.
Signed-off-by: Roger Quadros
---
net/mdio-uclass.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 6fc7034111..0ebfb2f134 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -6,6 +6,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -121,6 +123,42 @@ static int mdio_reset(struct mii_dev *mii_bus)
return dm_mdio_reset(mii_bus->priv);
}
+static int mdio_bind_phy_nodes(struct udevice *mdio_dev)
+{
+ ofnode mdio_node, phy_node;
+ struct udevice *phy_dev;
+ const char *node_name;
+ int ret;
+
+ mdio_node = dev_ofnode(mdio_dev);
+ if (!ofnode_valid(mdio_node)) {
+ dev_dbg(mdio_dev, "invalid ofnode for mdio_dev\n");
+ return -ENXIO;
+ }
+
+ ofnode_for_each_subnode(phy_node, mdio_node) {
+ node_name = ofnode_get_name(phy_node);
+ dev_dbg(mdio_dev, "* Found child node: '%s'\n", node_name);
+ ret = device_bind_driver_to_node(mdio_dev,
+"eth_phy_generic_drv",
+node_name, phy_node, _dev);
+ if (ret) {
+ dev_dbg(mdio_dev, " - Eth phy binding error: %d\n",
ret);
+ continue;
+ }
+
+ dev_dbg(mdio_dev, " - bound phy device: '%s'\n", node_name);
+ ret = device_probe(phy_dev);
+ if (ret) {
+ dev_dbg(mdio_dev, "Device '%s' probe failed\n",
phy_dev->name);
+ device_unbind(phy_dev);
+ continue;
+ }
+ }
+
+ return 0;
+}
+
static int dm_mdio_post_probe(struct udevice *dev)
{
struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
@@ -154,6 +192,9 @@ static int dm_mdio_post_probe(struct udevice *dev)
}
}
+ if (CONFIG_IS_ENABLED(DM_ETH_PHY))
+ mdio_bind_phy_nodes(dev);
+
return mdio_register(pdata->mii_bus);
}
--
2.34.1
[PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet
Currently, the GPIO Reset Device Tree properties of the PHY node are ignored when the PHY is probed via mdio-uclass driver [1]. To resolve this, for each child of the MDIO bus node, bind and probe the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled. This should now show the generic_phy_driver in "dm tree" and also apply the GPIO reset before the MDIO bus driver scans the bus for the PHYs. ethernet 0 [ + ] am65_cpsw_nuss_port | |-- ethernet@800port@1 bootdev 3 [ ] eth_bootdev | | `-- port@1.bootdev mdio 0 [ + ] cpsw_mdio | `-- mdio@f00 eth_phy_ge0 [ + ] eth_phy_generic_drv | |-- ethernet-phy@0 eth_phy_ge1 [ + ] eth_phy_generic_drv | `-- ethernet-phy@1 To test this on Beagleplay, the following series is required [1] Switch am65-cpsw to DM MDIO https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/ The last 3 patches are marked [not-for-merge]. They are to show how the whole solution can work to fix Ethernet on Beagleplay, which has been broken so far. Those DT patches will be sent once the device tree changes are merged into Linux tree. Signed-off-by: Roger Quadros --- Roger Quadros (5): net: mdio-uclass: Bind and probe generic Ethernet PHY driver configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229 [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO arch/arm/dts/k3-am62-main.dtsi | 126 ++--- arch/arm/dts/k3-am62-mcu.dtsi| 4 +- arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- arch/arm/dts/k3-am62-thermal.dtsi| 5 +- arch/arm/dts/k3-am62-verdin-dev.dtsi | 4 +- arch/arm/dts/k3-am62-verdin-wifi.dtsi| 1 - arch/arm/dts/k3-am62-verdin.dtsi | 76 +++--- arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- arch/arm/dts/k3-am62.dtsi| 4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + arch/arm/dts/k3-am625-beagleplay.dts | 66 - arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- arch/arm/dts/k3-am625-sk.dts | 4 +- arch/arm/dts/k3-am625.dtsi | 4 +- arch/arm/dts/k3-am62a-main.dtsi | 201 +-- arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- arch/arm/dts/k3-am62a.dtsi | 4 +- arch/arm/dts/k3-am62a7-sk.dts| 162 - arch/arm/dts/k3-am62a7.dtsi | 4 +- arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- configs/am62x_beagleplay_a53_defconfig | 2 +- net/mdio-uclass.c| 41 ++ 24 files changed, 825 insertions(+), 130 deletions(-) --- base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 Best regards, -- Roger Quadros
Re: [PATCH 0/3] Fix driver for misc/atsha204a
On Mon, 19 Feb 2024 16:32:01 +, Michał Barnaś wrote: > Fix the driver to behave like the chip datasheet requires. > Improve wake up function to send low signal on SDA line for at least > 60us as chip requires to wake up. Fix sleep function to move the chip > into sleep mode, not into idle mode. Remove unnecessary for loop, > which would never run for more than one iteration. > > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
On Tue, 5 Mar 2024 at 18:21, Caleb Connolly wrote:
>
>
>
> On 05/03/2024 12:35, Sumit Garg wrote:
> > Hi Caleb,
> >
> > On Mon, 4 Mar 2024 at 22:22, Caleb Connolly
> > wrote:
> >>
> >> This adjusts OF_UPSTREAM to behave more like the kernel by allowing for
> >> all the devicetree files for a given vendor to be compiled. This is
> >> useful for Qualcomm in particular as most boards are supported by a
> >> single U-Boot build just provided with a different DT.
> >>
> >> Signed-off-by: Caleb Connolly
> >> ---
> >> dts/Kconfig | 24
> >> scripts/Makefile.dts | 17 -
> >> 2 files changed, 40 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/dts/Kconfig b/dts/Kconfig
> >> index b9b6367154ef..67d9dc489856 100644
> >> --- a/dts/Kconfig
> >> +++ b/dts/Kconfig
> >> @@ -100,8 +100,32 @@ config OF_UPSTREAM
> >> However, newer boards whose devicetree source files haven't
> >> landed in
> >> the dts/upstream subtree, they can override this option to have
> >> the
> >> DT build from existing U-Boot tree location instead.
> >>
> >> +config OF_UPSTREAM_BUILD_VENDOR
> >> + bool "Build all devicetree files for a particular vendor"
> >> + depends on OF_UPSTREAM
> >> + help
> >> + Enable building all devicetree files for a particular vendor.
> >> This
> >
> > Do we really want to build all the DTBs even if many of those aren't
> > supported by U-Boot at all? I would have rather added Makefile targets
> > for boards which really supports a single defconfig eg.
> > qcom_defconfig.
>
> Yes, for the 4 Qualcomm SoCs currently supported there are 51 dts
> targets that ought to be able to run U-Boot to some extent
Have you tested U-Boot on all of them? IMO, it would be good to make
people aware about supported boards via listing their DTs at least.
>
> $ ls -l dts/upstream/src/arm6/qcom/{msm8916,sdm845,msm8996,qcs404}*.dts\
> | wc -l
> 51
>
qcom_defconfig currently only supports sdm845 and qcs404.
> What do you mean by a "makefile target"? Like copying
> arch/arm64/boot/dts/qcom/Makefile from Linux? I guess my concern here
> would be keeping it in sync, and introducing additional busywork when
> porting.
See following diff:
diff --git a/dts/upstream/src/arm64/Makefile b/dts/upstream/src/arm64/Makefile
index 9a8f6aa35846..ecc15021cb08 100644
--- a/dts/upstream/src/arm64/Makefile
+++ b/dts/upstream/src/arm64/Makefile
@@ -2,6 +2,10 @@
include $(srctree)/scripts/Makefile.dts
+dtb-$(CONFIG_ARCH_SNAPDRAGON) += qcom/sdm845-db845c.dtb \
+ qcom/sdm845-samsung-starqltechn.dtb \
+ qcom/qcs404-evb-4000.dtb
+
targets += $(dtb-y)
>
> We do have a lot of Qualcomm DTS files, it takes maybe 10 seconds to
> compile them all on my machine, but that's only once. With incremental
> builds this becomes largely irrelevant.
Maybe someone cares about build time too but that's not my primary
concern. We shouldn't be giving the false impression that all the DTs
present in the vendor directory are supported by U-Boot.
-Sumit
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
On 05/03/2024 12:35, Sumit Garg wrote:
> Hi Caleb,
>
> On Mon, 4 Mar 2024 at 22:22, Caleb Connolly wrote:
>>
>> This adjusts OF_UPSTREAM to behave more like the kernel by allowing for
>> all the devicetree files for a given vendor to be compiled. This is
>> useful for Qualcomm in particular as most boards are supported by a
>> single U-Boot build just provided with a different DT.
>>
>> Signed-off-by: Caleb Connolly
>> ---
>> dts/Kconfig | 24
>> scripts/Makefile.dts | 17 -
>> 2 files changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/dts/Kconfig b/dts/Kconfig
>> index b9b6367154ef..67d9dc489856 100644
>> --- a/dts/Kconfig
>> +++ b/dts/Kconfig
>> @@ -100,8 +100,32 @@ config OF_UPSTREAM
>> However, newer boards whose devicetree source files haven't landed
>> in
>> the dts/upstream subtree, they can override this option to have the
>> DT build from existing U-Boot tree location instead.
>>
>> +config OF_UPSTREAM_BUILD_VENDOR
>> + bool "Build all devicetree files for a particular vendor"
>> + depends on OF_UPSTREAM
>> + help
>> + Enable building all devicetree files for a particular vendor. This
>
> Do we really want to build all the DTBs even if many of those aren't
> supported by U-Boot at all? I would have rather added Makefile targets
> for boards which really supports a single defconfig eg.
> qcom_defconfig.
Yes, for the 4 Qualcomm SoCs currently supported there are 51 dts
targets that ought to be able to run U-Boot to some extent
$ ls -l dts/upstream/src/arm6/qcom/{msm8916,sdm845,msm8996,qcs404}*.dts\
| wc -l
51
What do you mean by a "makefile target"? Like copying
arch/arm64/boot/dts/qcom/Makefile from Linux? I guess my concern here
would be keeping it in sync, and introducing additional busywork when
porting.
We do have a lot of Qualcomm DTS files, it takes maybe 10 seconds to
compile them all on my machine, but that's only once. With incremental
builds this becomes largely irrelevant.
>
> -Sumit
>
>> + is useful for generic U-Boot configurations where many boards can
>> + be supported with a single binary.
>> +
>> + This is only available for platforms using upstream devicetree.
>> +
>> +config OF_UPSTREAM_VENDOR
>> + string "Vendor to build all upstream devicetree files for"
>> + depends on OF_UPSTREAM_BUILD_VENDOR
>> + default "qcom" if ARCH_SNAPDRAGON
>> + default "rockchip" if ARCH_ROCKCHIP
>> + default "amlogic" if ARCH_MESON
>> + default "allwinner" if ARCH_SUNXI
>> + default "mediatek" if ARCH_MEDIATEK
>> + default "marvell" if ARCH_MVEBU
>> + default "xilinx" if ARCH_VERSAL || ARCH_ZYNQ
>> + default "nvidia" if ARCH_TEGRA
>> + help
>> + Select the vendor to build all devicetree files for.
>> +
>> choice
>> prompt "Provider of DTB for DT control"
>> depends on OF_CONTROL
>>
>> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts
>> index 5e2429c6170c..8005527f3df7 100644
>> --- a/scripts/Makefile.dts
>> +++ b/scripts/Makefile.dts
>> @@ -1,3 +1,18 @@
>> # SPDX-License-Identifier: GPL-2.0+
>>
>> -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE)
>> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
>> +dtb-y += $(patsubst %,%.dtb,\
>> + $(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST)
>> $(CONFIG_SPL_OF_LIST)))
>> +
>> +ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
>> +ifeq ($(CONFIG_ARM64),y)
>> +dt_dir := $(srctree)/dts/upstream/src/arm64
>> +else
>> +dt_dir := $(srctree)/dts/upstream/src/$(ARCH)
>> +endif
>> +
>> +dtb-vendor_dts := $(patsubst %.dts,%.dtb, \
>> + $(wildcard $(dt_dir)/$(subst ",,$(CONFIG_OF_UPSTREAM_VENDOR))/*.dts))
>> +
>> +dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts))
>> +
>> +endif
>>
>> --
>> 2.44.0
>>
--
// Caleb (they/them)
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
Hi Marek, On Tue Mar 5, 2024 at 1:31 PM CET, Marek Vasut wrote: > On 3/5/24 9:55 AM, Michael Walle wrote: > > On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote: > >> Some Winbond SPI NORs have special SR3 register which is > >> used among other things to control whether non-standard > >> "Individual Block/Sector Write Protection" (WPS bit) > >> locking scheme is activated. This non-standard locking > >> scheme is not supported by either U-Boot or Linux SPI > >> NOR stack so make sure it is disabled, otherwise the > >> SPI NOR may appear locked for no obvious reason. > > > > I don't think it is a good idea to just disable the WPS bit. > > Usually, that bit is non-volatile and the default is not set. > > Yes, that's right, the bit is non-volatile and should not be set unless > the MTD stack can handle it correctly. Currently, neither U-Boot nor > Linux does handle the bit at all, instead both attempt to use the > standard SPI NOR locking scheme which is also implemented by this SPI > NOR model and they both fail to unlock the SPI NOR that way. > > Note that the SR3 WPS bit only switches between two different locking > schemes (unset = standard SPI NOR locking scheme, set = custom winbond > locking scheme), setting SR3 WPS does not immediately imply the SPI NOR > is locked, rather the opposite. Out of manufacturing, the SPI NOR is > unlocked in either locking scheme. Depending on the SR3 WPS bit state, > different commands are used to lock and unlock the SPI NOR. > > I recently ran across a device which had the SR3 WPS bit incorrectly set > out of manufacturing of that device (i.e. before it was populated on a > board at board manufacturer) and the device was locked using the custom > locking scheme. I was not able to unlock or use that device because both > U-Boot and Linux tried to use the standard scheme for that purpose. Still, I don't think it makes any sense, to disable that bit for all winbond flashes just because there was one vendor which set it the wrong way - or the board manufacturer didn't test it and programmed the flash correctly. > Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in > Linux, since Linux that is booted afterward then gets a device that has > locking scheme configured in a way that Linux expects and can operate. > > Better yet, if some old LTS version of the Linux kernel is in use, it > will also work correctly, because this patch will configure the SPI NOR > locking scheme to what Linux expects it to be, before the SPI NOR is > handed over to that old kernel. Agreed, but it should *not* be done automatically and nor unconditionally. Please don't just overwrite any locking bits just because there is one flash which have it set. This should be either be a board level option or maybe expose some command line interface to let the user change the settings. > > Thus, > > there is likely someone, probably the manufacturer of the board, > > who intentionally set this bit. Now, with this patch it will get > > disabled *unconditionally*, forever. > > In my case, it is exactly the opposite, the SR3 WPS shouldn't have been > set and the device should not have been locked, but it was and that > confused both U-Boot and Linux. > > I would argue that if the board manufacturer intention was to lock the > SPI NOR, they would have had multiple better options at their disposal, > and those options should have been aligned with the software support: > - nWP pin of the SPI NOR could be tied low to enable WRITE PROTECT > - OTP bits could have been programmed to enable permanent WRITE PROTECT > - standard SPI NOR locking scheme could have been used too > > If they did set SR3 WPS and hoped that U-Boot or Linux would fail to > unlock the SPI NOR using standard locking scheme commands, that is I > think broken design. There might be software/OS which could handle that correctly. Also, if linux will ever learn to use the new locking scheme unconditionally, u-boot will always mess it up then. -michael signature.asc Description: PGP signature
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
On Tue, Mar 05, 2024 at 06:05:52PM +0530, Sumit Garg wrote: > Hi Caleb, > > On Mon, 4 Mar 2024 at 22:22, Caleb Connolly wrote: > > > > This adjusts OF_UPSTREAM to behave more like the kernel by allowing for > > all the devicetree files for a given vendor to be compiled. This is > > useful for Qualcomm in particular as most boards are supported by a > > single U-Boot build just provided with a different DT. > > > > Signed-off-by: Caleb Connolly > > --- > > dts/Kconfig | 24 > > scripts/Makefile.dts | 17 - > > 2 files changed, 40 insertions(+), 1 deletion(-) > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > index b9b6367154ef..67d9dc489856 100644 > > --- a/dts/Kconfig > > +++ b/dts/Kconfig > > @@ -100,8 +100,32 @@ config OF_UPSTREAM > > However, newer boards whose devicetree source files haven't > > landed in > > the dts/upstream subtree, they can override this option to have > > the > > DT build from existing U-Boot tree location instead. > > > > +config OF_UPSTREAM_BUILD_VENDOR > > + bool "Build all devicetree files for a particular vendor" > > + depends on OF_UPSTREAM > > + help > > + Enable building all devicetree files for a particular vendor. This > > Do we really want to build all the DTBs even if many of those aren't > supported by U-Boot at all? I would have rather added Makefile targets > for boards which really supports a single defconfig eg. > qcom_defconfig. Yes, I think this target is useful as it addresses some of Simon's earlier concerns with the feature. -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC 00/26] Drop DT upstream compatible dt-binding headers
Hi Caleb, On Mon, 4 Mar 2024 at 22:21, Caleb Connolly wrote: > > Many of the dt-binding headers in U-Boot are based on the upstream ones > from Linux, occasionally with minor changes. Although some have > additional things defined or are totally different. > > This series attempts to drop as many of these headers as is easily > possible. Those with differing APIs were left as-is. > > Most of this work was done with a script, with some manual fixing at the > end. > > All-in, we're dropping 393 of the 489 headers from include/dt-bindings. Glad to see that you have taken up this task. I would suggest you to run this through CI to be sure. > > Due to how the include paths are configured, U-Boot headers override > upstream ones by the same name, resulting in some upstream DTBs failing > to compile (e.g. those that use newer linux-event-codes.h). Swapping the > include order would conversely break a bunch of U-Boot DTS files and > drivers. The include paths ordering was done on purpose to avoid any breakages for U-Boot platforms. > > Hopefully this makes a good dent, and future efforts to align more > architectures with upstream DT will help drop the remaining headers. > +1 > In addition, the final patch in this series adds support for compiling > all upstream DTS files for a given vendor. This is useful in cases where > a single U-Boot binary can support many boards, and maintaining a list > of supported DTB files would quickly become arduous (as is the case with > Qualcomm). I have shared my concern on this patch. -Sumit > > To: Tom Rini > To: Neil Armstrong > To: Sumit Garg > To: Patrice Chotard > To: Patrick Delaunay > To: Jagan Teki > To: Simon Glass > To: Philipp Tomsich > To: Kever Yang > To: Lukasz Majewski > To: Sean Anderson > To: Sam Protsenko > To: Matthias Brugger > To: Peter Robinson > To: Joe Hershberger > To: Ramon Fried > To: Thierry Reding > To: Svyatoslav Ryhel > To: Michal Simek > To: Paul Barker > To: Weijie Gao > To: GSS_MTK_Uboot_upstream > To: Ryder Lee > To: Chunfeng Yun > To: Eugen Hristev > To: Rick Chen > To: Leo > To: Ryan Chen > To: Chia-Wei Wang > To: Aspeed BMC SW team > To: Joel Stanley > To: Kunihiko Hayashi > To: Dai Okamura > To: Eugeniy Paltsev > Cc: u-boot@lists.denx.de > Cc: u-boot-amlo...@groups.io > Cc: uboot-st...@st-md-mailman.stormreply.com > Cc: uboot-snps-...@synopsys.com > > Signed-off-by: Caleb Connolly > --- > Caleb Connolly (26): > qcom: drop clock dt-binding headers > qcom: drop remaining dt-binding headers > sunxi: drop clock dt-binding headers > sunxi: drop remaining dt-binding headers > imx: drop clock dt-binding headers > imx: drop dt-binding headers > amlogic: drop dt-binding headers > stm: drop dt-binding headers > rockchip: drop clock dt-binding headers > rockchip: drop remaining dt-binding headers > exynos: drop dt-binding headers > bcm: drop dt-binding headers > ti: drop dt-binding headers > tegra: drop clock dt-binding headers > tegra: drop dt-binding headers > xlnx: drop dt-binding headers > renesas: drop clock dt-binding headers > renesas: drop remaining dt-binding headers > mtk: drop dt-binding headers > microchip: drop dt-binding headers > hisi: drop dt-binding headers > sifive: drop clock headers > dt-bindings: drop clock headers > dt-bindings: drop remaining device headers > dt-bindings: drop generic headers > dts: support building all dtb files for a specific vendor > > arch/arm/dts/exynos7420.dtsi | 2 +- > arch/arm/dts/rk3399-u-boot.dtsi| 2 +- > arch/arm/dts/tegra186.dtsi | 2 +- > arch/riscv/dts/fu540-c000-u-boot.dtsi | 26 +- > drivers/clk/exynos/clk-exynos7420.c| 2 +- > drivers/clk/rockchip/clk_rk3399.c | 2 +- > drivers/clk/sifive/fu540-prci.c| 8 +- > drivers/mailbox/tegra-hsp.c| 2 +- > drivers/net/phy/dp83869.c | 2 + > drivers/pinctrl/rockchip/pinctrl-rk3568.c | 15 + > dts/Kconfig| 24 + > include/dt-bindings/arm/coresight-cti-dt.h | 37 - > include/dt-bindings/arm/ux500_pm_domains.h | 15 - > include/dt-bindings/ata/ahci.h | 20 - > include/dt-bindings/bus/moxtet.h | 16 - > include/dt-bindings/bus/ti-sysc.h | 28 - > include/dt-bindings/clk/ti-dra7-atl.h | 40 - > include/dt-bindings/clock/actions,s700-cmu.h | 118 --- > include/dt-bindings/clock/actions,s900-cmu.h | 129 --- > include/dt-bindings/clock/agilex-clock.h | 71 -- > include/dt-bindings/clock/am3.h| 227 - > .../clock/amlogic,a1-peripherals-clkc.h| 168 >
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
Hi Caleb, On Mon, 4 Mar 2024 at 22:22, Caleb Connolly wrote: > > This adjusts OF_UPSTREAM to behave more like the kernel by allowing for > all the devicetree files for a given vendor to be compiled. This is > useful for Qualcomm in particular as most boards are supported by a > single U-Boot build just provided with a different DT. > > Signed-off-by: Caleb Connolly > --- > dts/Kconfig | 24 > scripts/Makefile.dts | 17 - > 2 files changed, 40 insertions(+), 1 deletion(-) > > diff --git a/dts/Kconfig b/dts/Kconfig > index b9b6367154ef..67d9dc489856 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -100,8 +100,32 @@ config OF_UPSTREAM > However, newer boards whose devicetree source files haven't landed > in > the dts/upstream subtree, they can override this option to have the > DT build from existing U-Boot tree location instead. > > +config OF_UPSTREAM_BUILD_VENDOR > + bool "Build all devicetree files for a particular vendor" > + depends on OF_UPSTREAM > + help > + Enable building all devicetree files for a particular vendor. This Do we really want to build all the DTBs even if many of those aren't supported by U-Boot at all? I would have rather added Makefile targets for boards which really supports a single defconfig eg. qcom_defconfig. -Sumit > + is useful for generic U-Boot configurations where many boards can > + be supported with a single binary. > + > + This is only available for platforms using upstream devicetree. > + > +config OF_UPSTREAM_VENDOR > + string "Vendor to build all upstream devicetree files for" > + depends on OF_UPSTREAM_BUILD_VENDOR > + default "qcom" if ARCH_SNAPDRAGON > + default "rockchip" if ARCH_ROCKCHIP > + default "amlogic" if ARCH_MESON > + default "allwinner" if ARCH_SUNXI > + default "mediatek" if ARCH_MEDIATEK > + default "marvell" if ARCH_MVEBU > + default "xilinx" if ARCH_VERSAL || ARCH_ZYNQ > + default "nvidia" if ARCH_TEGRA > + help > + Select the vendor to build all devicetree files for. > + > choice > prompt "Provider of DTB for DT control" > depends on OF_CONTROL > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > index 5e2429c6170c..8005527f3df7 100644 > --- a/scripts/Makefile.dts > +++ b/scripts/Makefile.dts > @@ -1,3 +1,18 @@ > # SPDX-License-Identifier: GPL-2.0+ > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > +dtb-y += $(patsubst %,%.dtb,\ > + $(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) > $(CONFIG_SPL_OF_LIST))) > + > +ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) > +ifeq ($(CONFIG_ARM64),y) > +dt_dir := $(srctree)/dts/upstream/src/arm64 > +else > +dt_dir := $(srctree)/dts/upstream/src/$(ARCH) > +endif > + > +dtb-vendor_dts := $(patsubst %.dts,%.dtb, \ > + $(wildcard $(dt_dir)/$(subst ",,$(CONFIG_OF_UPSTREAM_VENDOR))/*.dts)) > + > +dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts)) > + > +endif > > -- > 2.44.0 >
Re: [PATCH v3] test/py: reset: Add a test for reset command
On 3/3/24 22:58, Angelo Dureghello wrote: Hi Tom, On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar Reviewed-by: Tom Rini --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 + 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635 looking into this. Is reset implemented in qemu? It should be skipped if it is not. Thanks, Michal
Re: [PATCH] mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
On 3/5/24 9:55 AM, Michael Walle wrote: [+ linux-mtd ] Hi Marek, Hi, On Mon Mar 4, 2024 at 5:16 PM CET, Marek Vasut wrote: Some Winbond SPI NORs have special SR3 register which is used among other things to control whether non-standard "Individual Block/Sector Write Protection" (WPS bit) locking scheme is activated. This non-standard locking scheme is not supported by either U-Boot or Linux SPI NOR stack so make sure it is disabled, otherwise the SPI NOR may appear locked for no obvious reason. I don't think it is a good idea to just disable the WPS bit. Usually, that bit is non-volatile and the default is not set. Yes, that's right, the bit is non-volatile and should not be set unless the MTD stack can handle it correctly. Currently, neither U-Boot nor Linux does handle the bit at all, instead both attempt to use the standard SPI NOR locking scheme which is also implemented by this SPI NOR model and they both fail to unlock the SPI NOR that way. Note that the SR3 WPS bit only switches between two different locking schemes (unset = standard SPI NOR locking scheme, set = custom winbond locking scheme), setting SR3 WPS does not immediately imply the SPI NOR is locked, rather the opposite. Out of manufacturing, the SPI NOR is unlocked in either locking scheme. Depending on the SR3 WPS bit state, different commands are used to lock and unlock the SPI NOR. I recently ran across a device which had the SR3 WPS bit incorrectly set out of manufacturing of that device (i.e. before it was populated on a board at board manufacturer) and the device was locked using the custom locking scheme. I was not able to unlock or use that device because both U-Boot and Linux tried to use the standard scheme for that purpose. Clearing this SR3 WPS bit fixes that problem, both in U-Boot and in Linux, since Linux that is booted afterward then gets a device that has locking scheme configured in a way that Linux expects and can operate. Better yet, if some old LTS version of the Linux kernel is in use, it will also work correctly, because this patch will configure the SPI NOR locking scheme to what Linux expects it to be, before the SPI NOR is handed over to that old kernel. Thus, there is likely someone, probably the manufacturer of the board, who intentionally set this bit. Now, with this patch it will get disabled *unconditionally*, forever. In my case, it is exactly the opposite, the SR3 WPS shouldn't have been set and the device should not have been locked, but it was and that confused both U-Boot and Linux. I would argue that if the board manufacturer intention was to lock the SPI NOR, they would have had multiple better options at their disposal, and those options should have been aligned with the software support: - nWP pin of the SPI NOR could be tied low to enable WRITE PROTECT - OTP bits could have been programmed to enable permanent WRITE PROTECT - standard SPI NOR locking scheme could have been used too If they did set SR3 WPS and hoped that U-Boot or Linux would fail to unlock the SPI NOR using standard locking scheme commands, that is I think broken design.
Pull request: u-boot-sunxi/master for v2024.04
Hi Tom, please pull the sunxi/master branch, containing some fixes and smaller changes for 2024.04. One fix makes the reboot more robust on some older board, another one stabilises the initial clock setup on the A10/A20. Two patches make sure our DRAM init does not actually change the content of the DRAM array, which allows to use DRAM for Linux' pstore functionality. We get SPI support for U-Boot proper for one more SoC, that patch was lingering around for a while, and should not affect other SoCs, so I am merging this now. As an added bonus, we get the defconfig file for a new board, the DT was already synced from the kernel tree. The CI looked happy with changes, and I tested them on five different boards with different SoCs. Please pull! Cheers, Andre == The following changes since commit eac52e4be4e234d563d6911737ee7ccdc0ada1f1: Merge patch series "ARM: renesas: Rename R-Mobile to Renesas" (2024-03-02 14:30:25 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to f1e6a718ebab0682d80601db404e8d842767becf: sunxi: restore modified memory (2024-03-05 01:16:56 +) Andre Przywara (1): sunxi: H616: Add OrangePi Zero 2W board support Andrey Skvortsov (2): sunxi: reorganize mctl_mem_matches_* functions sunxi: restore modified memory Ludwig Kormann (1): sunxi: sun4i: add missing sdelay() to clock_init_safe() Maksim Kiselev (1): spi: sunxi: Add support for R329/D1/R528/T113 SPI controller Philippe Coval (1): arm: sunxi: Reduce inrush current on Olimex A20-OLinuXino_MICRO configs arch/arm/dts/Makefile | 1 + arch/arm/include/asm/arch-sunxi/dram.h | 1 + arch/arm/mach-sunxi/clock_sun4i.c | 2 ++ arch/arm/mach-sunxi/dram_helpers.c | 32 ++-- arch/arm/mach-sunxi/dram_sunxi_dw.c| 13 board/sunxi/MAINTAINERS| 5 + configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 + configs/A20-OLinuXino_MICRO_defconfig | 1 + configs/orangepi_zero2w_defconfig | 30 ++ drivers/spi/spi-sunxi.c| 34 +- 10 files changed, 100 insertions(+), 20 deletions(-) create mode 100644 configs/orangepi_zero2w_defconfig
[PATCH] arm64: zynqmp: Add usb4 to the boot targets
USB4 has been added to the boot targets and
also add support to enable JTAG.
Signed-off-by: Shubhangi Shrikrushna Mahalle
Signed-off-by: Venkatesh Yadav Abbarapu
---
board/xilinx/zynqmp/zynqmp_kria.env | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/zynqmp/zynqmp_kria.env
b/board/xilinx/zynqmp/zynqmp_kria.env
index 0f940bd68f..7d3ad31226 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -44,7 +44,8 @@ usb_boot=usb start; if usb dev ${devnum}; then devtype=usb;
run scan_dev_for_boo
preboot=setenv boot_targets; setenv modeboot; run board_setup
# SOM specific boot methods
-som_cc_boot=if test ${card1_name} = SCK-KV-G; then setenv boot_targets mmc1
usb0 usb1 usb2 usb3 pxe dhcp && run distro_bootcmd; elif test ${card1_name} =
SCK-KR-G; then setenv boot_targets usb0 usb1 usb2 usb3 pxe dhcp && run
distro_bootcmd; else test ${card1_name} = SCK-KD-G; setenv boot_targets usb0
usb1 usb2 usb3 pxe dhcp && run distro_bootcmd; fi;"
+usb_boot_devices='usb0 usb1 usb2 usb3 usb4'
+som_cc_boot=if test ${card1_name} = SCK-KV-G; then setenv boot_targets mmc1
${usb_boot_devices} pxe dhcp jtag && run distro_bootcmd; elif test
${card1_name} = SCK-KR-G; then setenv boot_targets ${usb_boot_devices} pxe dhcp
jtag && run distro_bootcmd; else test ${card1_name} = SCK-KD-G; setenv
boot_targets ${usb_boot_devices} pxe dhcp jtag && run distro_bootcmd; fi;"
som_mmc_boot=setenv boot_targets mmc0 && run distro_bootcmd
k26_starter=SMK-K26-XCL2G
--
2.25.1
Re: [PATCH] implement policy_pcr commands to lock NV-indexes behind a PCR
On Tue, 20 Feb 2024 at 07:59, niek.nooij...@omron.com
wrote:
>
> Hi there
>
> After the NV-memory read/write code I'm here again for another patch.
> This time I implemented code to allow an NV-index to be locked behind a PCR
> value.
> This can be used together with the new measured-boot code allowing you to
> store encryption keys inside the TPM and locking them behind PCR's.
> To do that you:
>
> set the PCR's to some value
> start an auth session
> create a policy_pcr
> get that policy's digest
> use NV_define together with the policy digest.
> use nv_write together with the session handle in which the policy_digest was
> generated.
>
> After another PCR extend, the NV index will be locked and cannot be read.
> At next boot, when the PCR's are in the correct state again, you can read the
> NV_index by authenticating with a PCR value.
> To do that you:
>
> set the PCR's to the correct value
> start an auth session
> create a policy_pcr
> nv_read whilst providing the session handle in which the policy was created.
>
>
> It might not be perfect yet, but at least it vastly extends the TPM
> capabilities of uboot.
> I generated the patch against latest github master.
> Feedback is welcome.
>
> Niek
>
> =START PATCH
> From 8d3ea3130794d9db51d95056eb42044a2c5d9f4f Mon Sep 17 00:00:00 2001
> From: Niek Nooijens
> Date: Tue, 20 Feb 2024 13:42:57 +0900
> Subject: [PATCH] implement policy_pcr commands to lock NV-indexes behind a PCR
> policy
>
> Signed-off-by: Niek Nooijens
> ---
> cmd/tpm-v2.c | 258 +++
> include/tpm-common.h | 2 +
> include/tpm-v2.h | 126 ---
> lib/tpm-v2.c | 355 +--
> lib/tpm_api.c| 4 +-
> 5 files changed, 669 insertions(+), 76 deletions(-)
>
> diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> index 7e479b9dfe..6b6f4629ea 100644
> --- a/cmd/tpm-v2.c
> +++ b/cmd/tpm-v2.c
> @@ -356,6 +356,222 @@ static int do_tpm_pcr_setauthvalue(struct cmd_tbl
> *cmdtp, int flag,
> key, key_sz));
> }
>
> +static int do_tpm_nv_define(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + struct tpm_chip_priv *priv;
> + u32 nv_addr, nv_size, rc;
> + void *policy_addr = NULL;
> + size_t policy_size = 0;
> + int ret;
> +
> + u32 nv_attributes = TPMA_NV_PLATFORMCREATE | TPMA_NV_OWNERWRITE |
> TPMA_NV_OWNERREAD | TPMA_NV_PPWRITE | TPMA_NV_PPREAD;
You need to break this at 80 chars
u32 nv_attributes = TPMA_NV_PLATFORMCREATE | TPMA_NV_OWNERWRITE | \
...etc
> +
> + if (argc < 3 && argc > 7)
> + return CMD_RET_USAGE;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + priv = dev_get_uclass_priv(dev);
> + if (!priv)
> + return -EINVAL;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_strtoul(argv[2], NULL, 0);
> +
> + if (argc > 3)
> + nv_attributes = simple_strtoul(argv[3], NULL, 0);
> +
> + if (argc > 4) {
> + policy_addr = map_sysmem(simple_strtoul(argv[4], NULL, 0), 0);
> + nv_attributes |= (TPMA_NV_POLICYREAD | TPMA_NV_POLICYWRITE);
> //obligated, might as well force it
I am not sure I understand the comment
> + if (argc < 5)
> + return CMD_RET_USAGE;
> + policy_size = simple_strtoul(argv[5], NULL, 0);
> + }
> +
> + rc = tpm2_nv_define_space(dev, nv_addr, nv_size, nv_attributes,
> policy_addr, policy_size);
> +
You don't need an empty line here
> + if (rc)
> + printf("ERROR: nv_define #%u returns: 0x%x\n", nv_addr, rc);
> +
> + if (policy_addr)
> + unmap_sysmem(policy_addr);
Later down the code, you unconditionally call unmap_sysmem even for
NULL. I don't think we need the check here either
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_undefine(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, ret, rc;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + if (argc != 2)
> + return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> + rc = tpm2_nv_undefine_space(dev, nv_addr);
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_read_value(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, nv_size, rc;
> + void *session_addr = NULL;
> + int ret;
> + void *out_data;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + if (argc < 4)
> + return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_strtoul(argv[2], NULL, 0);
Please pull u-boot-marvell/master
Hi Tom, please pull this next batch of mostly Marvell related patches: - net: mv88e6xxx: fix missing SMI address initialization (Marek) - mvebu: turris_omnia: Enable networking via ethernet switch (Marek) - mvebu: helios-4: add config fragment for spi booting et al (Josua) - rng: Add Turris Mox rTWM RNG driver (Max) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=341=results Thanks, Stefan The following changes since commit 773cb2bca7743406e34ab4f441fc0a8a0d200a19: Merge tag 'u-boot-imx-master-20240304' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-03-04 15:41:38 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to d61b485dbd766970816ae9da09004dc4b30f8395: rng: Add Turris Mox rTWM RNG driver (2024-03-05 08:27:59 +0100) Josua Mayer (3): arm: dts: armada-38x-solidrun-microsom: configure i2c0 bus arm: mvebu: helios4_defconfig: enable setexpr command board: helios-4: add config fragment for spi booting Marek Mojík (2): net: mv88e6xxx: fix missing SMI address initialization arm: mvebu: turris_omnia: Enable networking via ethernet switch Max Resch (1): rng: Add Turris Mox rTWM RNG driver arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 51 ++ arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 5 + board/kobol/helios4/spiboot.config | 4 + configs/helios4_defconfig| 1 - configs/turris_omnia_defconfig | 2 + drivers/net/mv88e6xxx.c | 8 ++ drivers/rng/Kconfig | 8 ++ drivers/rng/Makefile | 1 + drivers/rng/turris_rwtm_rng.c| 123 +++ 9 files changed, 202 insertions(+), 1 deletion(-) create mode 100644 board/kobol/helios4/spiboot.config create mode 100644 drivers/rng/turris_rwtm_rng.c
Re: [PATCH v5] rng: Add Turris Mox rTWM RNG driver
On 2/15/24 17:57, Max Resch wrote:
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
from CZ.NIC in the secure processor.
Signed-off-by: Max Resch
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes in v5:
- check return code turris_rwtm_rng_fill_entropy
- remove empty line
Changes in v4:
- wrongful/missing git rebase
Changes in v3:
- More meaningful variable names in accordance with review
Changes in v2:
- Removed ring buffer implementation
drivers/rng/Kconfig | 8 +++
drivers/rng/Makefile | 1 +
drivers/rng/turris_rwtm_rng.c | 123 ++
3 files changed, 132 insertions(+)
create mode 100644 drivers/rng/turris_rwtm_rng.c
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index a89c899568..cd72852a47 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -105,4 +105,12 @@ config RNG_JH7110
help
Enable True Random Number Generator in StarFive JH7110 SoCs.
+config RNG_TURRIS_RWTM
+ bool "Turris Mox TRNG in Secure Processor"
+ depends on DM_RNG && ARMADA_3700
+ help
+ Use TRNG in Turris Mox Secure Processor Firmware. Can be used
+ on other Armada-3700 devices (like EspressoBin) if Secure
+ Firmware from CZ.NIC is used.
+
endif
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 7e64c4cdfc..ecae1a3da3 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
obj-$(CONFIG_TPM_RNG) += tpm_rng.o
obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
+obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
diff --git a/drivers/rng/turris_rwtm_rng.c b/drivers/rng/turris_rwtm_rng.c
new file mode 100644
index 00..ca808c4579
--- /dev/null
+++ b/drivers/rng/turris_rwtm_rng.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (c) 2024, Max Resch
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* size of entropy buffer */
+#define RNG_BUFFER_SIZE128U
+
+struct turris_rwtm_rng_priv {
+ phys_addr_t buffer;
+};
+
+static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t size)
+{
+ u32 args[3] = { 1, (u32)entropy, size };
+ int ret;
+
+ /* flush data cache */
+ flush_dcache_range(entropy, entropy + size);
+
+ /*
+* get entropy
+* args[0] = 1 copies BYTES array in args[1] of length args[2]
+*/
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, 3, NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ /* invalidate data cache */
+ invalidate_dcache_range(entropy, entropy + size);
+
+ return 0;
+}
+
+static int turris_rwtm_rng_random_read(struct udevice *dev, void *data, size_t
count)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys;
+ size_t size;
+ int ret;
+
+ phys = priv->buffer;
+
+ while (count) {
+ size = min_t(size_t, RNG_BUFFER_SIZE, count);
+
+ ret = turris_rwtm_rng_fill_entropy(phys, size);
+ if (ret < 0)
+ return ret;
+
+ memcpy(data, (void *)phys, size);
+ count -= size;
+ data = (u8 *)data + size;
+ }
+
+ return 0;
+}
+
+static int turris_rwtm_rng_probe(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ u32 args[] = { 0 };
+ int ret;
+
+ /*
+* check if the random command is supported
+* args[0] = 0 would copy 16 DWORDS entropy to out but we ignore them
+*/
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, ARRAY_SIZE(args), NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ /* entropy buffer */
+ priv->buffer = 0;
+
+ /* buffer address need to be aligned */
+ dma_alloc_coherent(RNG_BUFFER_SIZE, (unsigned long *)>buffer);
+ if (!priv->buffer)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int turris_rwtm_rng_remove(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys = priv->buffer;
+
+ dma_free_coherent((void *)phys);
+
+ return 0;
+}
+
+static const struct dm_rng_ops turris_rwtm_rng_ops = {
+ .read = turris_rwtm_rng_random_read,
+};
+
+/*
+ * only Turris MOX firmware has the RNG but allow all probable devices to be
+ * probed the default firmware will just reject the probe
+ */
+static const struct udevice_id turris_rwtm_rng_match[] = {
+ { .compatible = "cznic,turris-mox-rwtm" },
+ { .compatible = "marvell,armada-3700-rwtm-firmware" },
+ {},
+};
+
+U_BOOT_DRIVER(turris_rwtm_rng) = {
+ .name = "turris-rwtm-rng",
+ .id = UCLASS_RNG,
+ .of_match = turris_rwtm_rng_match,
+ .ops=
Re: [PATCH v2 3/3] board: helios-4: add config fragment for spi booting
On 2/2/24 16:13, Josua Mayer wrote: Add a config fragment with required differences for booting from spi flash instead of sd-card (default). Settings for environment location are based on vendor u-boot: https://github.com/kobol-io/u-boot/blob/helios4/include/configs/helios4.h#L59 The fragment can be applied on top of helios4_defconfig by make: make helios4_defconfig spiboot.config Signed-off-by: Josua Mayer Applied to u-boot-marvell/master Thanks, Stefan --- board/kobol/helios4/spiboot.config | 4 1 file changed, 4 insertions(+) diff --git a/board/kobol/helios4/spiboot.config b/board/kobol/helios4/spiboot.config new file mode 100644 index 00..5ffb7d2e3b --- /dev/null +++ b/board/kobol/helios4/spiboot.config @@ -0,0 +1,4 @@ +CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y +# CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC is not set +CONFIG_ENV_OFFSET=0x10 +CONFIG_ENV_SECT_SIZE=0x1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/3] arm: mvebu: helios4_defconfig: enable setexpr command
On 2/2/24 16:13, Josua Mayer wrote: Update the helios4 defconfig to enable the 'setexpr' command, which is a default and useful for various complex boot-scripts. Signed-off-by: Josua Mayer Applied to u-boot-marvell/master Thanks, Stefan --- configs/helios4_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig index 04194004f0..73f0638344 100644 --- a/configs/helios4_defconfig +++ b/configs/helios4_defconfig @@ -44,7 +44,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 1/3] arm: dts: armada-38x-solidrun-microsom: configure i2c0 bus
On 2/2/24 16:13, Josua Mayer wrote:
SolidRun Armada-388 SoM has an i2c bus supporting on-som eeprom, and
peripherals on a carrier.
armada-38x.dtsi disables this bus by default, it should be enabled by
som or carrier dts.
Linux has moved i2c0 from helios-4 board dts to som dtsi, including
status, pinctrl and clock speed.
Copy these settings from mainline.
This fixes accessing i2c bus from u-boot commandline.
Signed-off-by: Josua Mayer
Applied to u-boot-marvell/master
Thanks,
Stefan
---
arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
index f6ae784bed..1540162e03 100644
--- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
@@ -99,6 +99,11 @@
};
{
+ clock-frequency = <40>;
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
eeprom@53 {
compatible = "atmel,24c02";
reg = <0x53>;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell] arm: mvebu: turris_omnia: Enable networking via ethernet switch
On 12/19/23 10:55, Marek Behún wrote:
From: Marek Mojík
The Turris Omnia contains the Marvell 88E6176 ethernet switch. Add
config options and device tree to enable the support.
Signed-off-by: Marek Mojík
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Stefan, this patch depends on
[v2] net: mv88e6xxx: fix missing SMI address initialization
https://patchwork.ozlabs.org/project/uboot/patch/62eoapvurxkedw74vpzb55q3nuqgb4cef3bl2laayx57cpjzus@vlpx57cjc4ph/
---
.../dts/armada-385-turris-omnia-u-boot.dtsi | 51 +++
configs/turris_omnia_defconfig| 2 +
2 files changed, 53 insertions(+)
diff --git a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
index 509d6ca69c..c63a331d69 100644
--- a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
@@ -35,6 +35,57 @@
};
};
+ {
+ switch@10 {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ sw_phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ sw_phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ sw_phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+
+ sw_phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+ };
+ ports {
+ ports@0 {
+ phy-handle = <_phy0>;
+ phy-mode = "internal";
+ };
+ ports@1 {
+ phy-handle = <_phy1>;
+ phy-mode = "internal";
+ };
+ ports@2 {
+ phy-handle = <_phy2>;
+ phy-mode = "internal";
+ };
+ ports@3 {
+ phy-handle = <_phy3>;
+ phy-mode = "internal";
+ };
+ ports@4 {
+ phy-handle = <_phy4>;
+ phy-mode = "internal";
+ };
+ };
+ };
+};
+
#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
{
flash@0 {
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 65d4a296e7..3aaee276ea 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -96,7 +96,9 @@ CONFIG_SPI_FLASH_WINBOND=y
CONFIG_SPI_FLASH_MTD=y
CONFIG_PHY_MARVELL=y
CONFIG_PHY_FIXED=y
+CONFIG_DM_DSA=y
CONFIG_PHY_GIGE=y
+CONFIG_MV88E6XXX=y
CONFIG_MVNETA=y
CONFIG_MII=y
CONFIG_MVMDIO=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2] net: mv88e6xxx: fix missing SMI address initialization
On 12/6/23 15:35, Marek Mojík wrote:
The mv88e6xxx driver does not currently initialize the smi_addr field, but
instead keeps the default zero value. This leads to driver being unusable
on devices where the switch is not on address zero of the mdio bus. Fix
this problem by reading the SMI address from device tree.
Signed-off-by: Marek Mojík
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/net/mv88e6xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
index c073f81e72..8fbbc1cacc 100644
--- a/drivers/net/mv88e6xxx.c
+++ b/drivers/net/mv88e6xxx.c
@@ -745,6 +745,7 @@ static int mv88e6xxx_probe(struct udevice *dev)
{
struct dsa_pdata *dsa_pdata = dev_get_uclass_plat(dev);
struct mv88e6xxx_priv *priv = dev_get_priv(dev);
+ fdt_addr_t smi_addr;
int val, ret;
if (ofnode_valid(dev_ofnode(dev)) &&
@@ -753,6 +754,13 @@ static int mv88e6xxx_probe(struct udevice *dev)
return -ENODEV;
}
+ smi_addr = dev_read_addr(dev);
+ if (smi_addr == FDT_ADDR_T_NONE) {
+ dev_err(dev, "Missing SMI address\n");
+ return -EINVAL;
+ }
+ priv->smi_addr = smi_addr;
+
/* probe internal mdio bus */
ret = mv88e6xxx_probe_mdio(dev);
if (ret)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 4/4] board: ti: am62x: evm: Update simple-framebuffer node in device-tree
Hi,
On 22/02/24 18:38, Devarsh Thakkar wrote:
> Update simple-framebuffer device-tree node by enumerating framebuffer
> related information in existing simple-framebuffer node in Linux
> device-tree file and enabling it.
>
> In case there is no simple-framebuffer stub detected in Linux kernel
> device-tree and video is still active, then update the device-tree to
> reserve the framebuffer region for the active splash screen.
>
> This helps preserve the splash screen till the display server takes over
> after OS is booted.
>
> Signed-off-by: Devarsh Thakkar
> ---
> board/ti/am62x/evm.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
> index 88e02155ee..c825af3368 100644
> --- a/board/ti/am62x/evm.c
> +++ b/board/ti/am62x/evm.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -118,3 +119,21 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
> #endif
> }
> #endif
> +
> +#if defined(CONFIG_OF_BOARD_SETUP)
> +int ft_board_setup(void *blob, struct bd_info *bd)
> +{
> + int ret = -1;
> +
> + if (IS_ENABLED(CONFIG_FDT_SIMPLEFB))
> + ret = fdt_simplefb_enable_and_mem_rsv(blob);
> +
This needs to be protected with IS_ENABLED(CONFIG_VIDEO) too to avoid below
errors when CONFIG_VIDEO is disabled :
/home/devarsht/ti/ti-u-boot/board/ti/am62x/evm.c:102: undefined reference to
`video_is_active'
aarch64-none-linux-gnu-ld.bfd:
/home/devarsht/ti/ti-u-boot/board/ti/am62x/evm.c:104: undefined reference to
`fdt_add_fb_mem_rsv' \
I will send out a V2 of this patch.
Regards
Devarsh
> + /* If simplefb is not enabled and video is active, then at least reserve
> + * the framebuffer region to preserve the splash screen while OS is
> booting
> + */
> + if (ret && video_is_active())
> + return fdt_add_fb_mem_rsv(blob);
> +
> + return 0;
> +}
> +#endif
Re: [PATCH v2] net: mv88e6xxx: fix missing SMI address initialization
Hi Marek,
On 3/4/24 15:48, Marek Behún wrote:
Hi Stefan,
On Wed, 14 Feb 2024 08:50:16 +0100
Stefan Roese wrote:
Hi Ramon,
On 1/9/24 10:37, Stefan Roese wrote:
On 12/18/23 17:09, Marek Behún wrote:
On Wed, 6 Dec 2023 15:35:56 +0100
Marek Mojík wrote:
The mv88e6xxx driver does not currently initialize the smi_addr
field, but
instead keeps the default zero value. This leads to driver being
unusable
on devices where the switch is not on address zero of the mdio bus. Fix
this problem by reading the SMI address from device tree.
Signed-off-by: Marek Mojík
---
drivers/net/mv88e6xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
index c073f81e72..8fbbc1cacc 100644
--- a/drivers/net/mv88e6xxx.c
+++ b/drivers/net/mv88e6xxx.c
@@ -745,6 +745,7 @@ static int mv88e6xxx_probe(struct udevice *dev)
{
struct dsa_pdata *dsa_pdata = dev_get_uclass_plat(dev);
struct mv88e6xxx_priv *priv = dev_get_priv(dev);
+ fdt_addr_t smi_addr;
int val, ret;
if (ofnode_valid(dev_ofnode(dev)) &&
@@ -753,6 +754,13 @@ static int mv88e6xxx_probe(struct udevice *dev)
return -ENODEV;
}
+ smi_addr = dev_read_addr(dev);
+ if (smi_addr == FDT_ADDR_T_NONE) {
+ dev_err(dev, "Missing SMI address\n");
+ return -EINVAL;
+ }
+ priv->smi_addr = smi_addr;
+
/* probe internal mdio bus */
ret = mv88e6xxx_probe_mdio(dev);
if (ret)
Reviewed-by: Marek Behún
Reviewed-by: Stefan Roese
Ramon, this patch was assigned to me as an Marvell MVEBU patch
depends on it. I've assigned it to you now. Or if it's okay that
I pull it with the Marvell tree, just let me know.
Any updates on this?
Thanks,
Stefan
Stefan, it seems that Ramon is unavailable for this.
Can we take this? We've been using it on Omnia and it works correctly.
Yes, I also thought about pulling this one in. As a matter of fact,
I'm currently busy with creating a pull request for Tom.
Thanks,
Stefan
Re: [PATCH] configs: rockchip: rock5b: enable environment
Hi all, On 3/5/24 10:36, Christopher Obbard wrote: [You don't often get email from chris.obb...@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Jonas & Trevor, On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote: Hi Trevor, On 2024-03-05 03:10, Trevor Woerner wrote: Following the pattern of other Rockchip devices, enable the U-Boot environment to be stored in MMC. This patch specifically assumes the environment will be stored on the SDcard. This board has SPI flash, so storing env in SPI flash is probably a better default. I agree with that. However, preferably the env should be stored/loaded from the same device that TPL/SPL was loaded from. Do you know if there is some mechanism in U-Boot to do this already ? We do this for our Theobroma boards, though we use the same device that U-Boot proper was loaded from, and not the one that TPL+SPL was loaded from but the logic could be more or less the same. https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L92-L152 is what you need. The first function is to differentiate between SD card and eMMC, the second actually returns the **kind** of medium the environment is stored on (so MMC or SPI-flash for Theobroma boards). Instead of https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L94-L95 you probably want to use board_spl_was_booted_from(). Note that to you need the MMC and SPI controllers to be bound in U-Boot proper **before relocation** for this to work. c.f. https://lore.kernel.org/u-boot/20240221-jaguar-v3-15-1f256a822...@theobroma-systems.com/ It could be useful to enable autodetection on many boards which can boot U- Boot from either SPI flash / eMMC / SD card. There's been an attempt recently: https://lore.kernel.org/u-boot/20240226011413.435713-2-benwolsief...@gmail.com/ though only for the MMC part of the equation. Cheers, Quentin
Re: [PATCH] configs: rockchip: rock5b: enable environment
Hi Christopher, On 2024-03-05 10:36, Christopher Obbard wrote: > Hi Jonas & Trevor, > > On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote: >> Hi Trevor, >> >> On 2024-03-05 03:10, Trevor Woerner wrote: >>> Following the pattern of other Rockchip devices, enable the U-Boot >>> environment to be stored in MMC. This patch specifically assumes the >>> environment will be stored on the SDcard. >> >> This board has SPI flash, so storing env in SPI flash is probably a >> better default. > > I agree with that. > >> However, preferably the env should be stored/loaded from >> the same device that TPL/SPL was loaded from. > > Do you know if there is some mechanism in U-Boot to do this already ? > > It could be useful to enable autodetection on many boards which can boot U- > Boot from either SPI flash / eMMC / SD card. > I think it should be possible with a combo of env_get_location(), arch_env_get_location() and mmc_get_env_dev(). board/theobroma-systems/common/common.c does something like this already, other arch also have these functions defined, for inspiration. Regards, Jonas > > Cheers! > > Chris > >> >> Regards, >> Jonas >> >>> >>> Signed-off-by: Trevor Woerner >>> --- >>> configs/rock5b-rk3588_defconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b- >>> rk3588_defconfig >>> index 0595325e8107..64a242003aa1 100644 >>> --- a/configs/rock5b-rk3588_defconfig >>> +++ b/configs/rock5b-rk3588_defconfig >>> @@ -60,6 +60,8 @@ 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_ENV_IS_IN_MMC=y >>> +CONFIG_SYS_MMC_ENV_DEV=1 >>> CONFIG_SPL_DM_SEQ_ALIAS=y >>> CONFIG_SPL_REGMAP=y >>> CONFIG_SPL_SYSCON=y >>
