Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
> From: Sahil Malhotra > > This patch enables the DTB overlay feature for LS platforms. Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY. Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too? -michael
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
Dear Tom, In message <2026184146.GF24579@bill-the-cat> you wrote: > > Because honestly, the more I read this, the more I think > https://patchwork.ozlabs.org/project/uboot/patch/2025121152.3470910-1-m= > ich...@walle.cc/ > is essentially the right direction. There's no reason for 'net list' to > be using the environment here when ->enetaddr is what's being used by > the stack. The use case of "I want to make my locally administered MAC > persist because my USB ethernet adapter lacks a MAC address" is solved > via the environment already. If the MAC address is not placed in the environment, then how can a user query the currently used MAC address? All documentation says basically: run "printenv ethaddr". Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Plan to throw one away. You will anyway." - Fred Brooks, "The Mythical Man Month"
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
From: Sahil Malhotra SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
RE: Your message to U-Boot awaits moderator approval
Thanks Tom, Regards, Sahil Malhotra -Original Message- From: Tom Rini Sent: Tuesday, November 16, 2021 6:29 PM To: Sahil Malhotra (OSS) Cc: u-boot-ow...@lists.denx.de; u-boot@lists.denx.de; Sahil Malhotra Subject: Re: Your message to U-Boot awaits moderator approval On Tue, Nov 16, 2021 at 10:26:37AM +, Sahil Malhotra (OSS) wrote: > Hi, > > I am trying to send some patches on u-boot@lists.denx.de but every time I am > getting reply "Your message to U-Boot awaits moderator approval". > Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the > list u-boot@lists.denx.de. > > Tried multiple times, but always getting this reply. > Any help regarding this is really appreciated. Yes, your messages and then subscription (I'm not sure whey, on the latter) were waiting for approval, which is now done. -- Tom
Re: [PATCH 11/14] board: synquacer: developerbox: Don't set gd->env_addr to default_environment
Hi Marek,
I found this cause a synchronous abort on boot on the developerbox
when the env_vars on SPI flash is corrupted. See below log.
Can we revert it? I confirmed that reverting this patch fixes the problem.
Thank you,
[2021-11-17 13:49:19] U-Boot 2021.10-01018-g535870f3b0 (Nov 17 2021 -
13:45:48 +0900)
[2021-11-17 13:49:19]
[2021-11-17 13:49:19] CPU: SC2A11:Cortex-A53 MPCore 24cores
[2021-11-17 13:49:19] Model: Socionext Developer Box
[2021-11-17 13:49:19] DRAM: 3.9 GiB
[2021-11-17 13:49:20] MMC: sdhci@5230: 0
[2021-11-17 13:49:20] Loading Environment from SPIFlash... SF:
Detected mx66u51235f with page size 2
56 Bytes, erase size 4 KiB, total 64 MiB
[2021-11-17 13:49:20] *** Warning - bad CRC, using default environment
[2021-11-17 13:49:20]
[2021-11-17 13:49:20] "Synchronous Abort" handler, esr 0x96000210
[2021-11-17 13:49:20] elr: 08245cbc lr : 08245ca4 (reloc)
[2021-11-17 13:49:20] elr: fbf5acbc lr : fbf5aca4
[2021-11-17 13:49:20] x0 : 000a x1 : 0001
[2021-11-17 13:49:20] x2 : x3 : 00010301
[2021-11-17 13:49:20] x4 : x5 :
[2021-11-17 13:49:20] x6 : x7 :
[2021-11-17 13:49:20] x8 : 0004 x9 : 0008
[2021-11-17 13:49:20] x10: 000186a0 x11: ffd0
[2021-11-17 13:49:20] x12: 0006 x13: 0001869f
[2021-11-17 13:49:20] x14: faee0b00 x15:
[2021-11-17 13:49:20] x16: fbf52b24 x17:
[2021-11-17 13:49:20] x18: faee4d80 x19: faf1aad8
[2021-11-17 13:49:20] x20: 0828eadf x21: 000a
[2021-11-17 13:49:20] x22: 0020 x23: fbfaa016
[2021-11-17 13:49:20] x24: faee4e70 x25: 0828eadf
[2021-11-17 13:49:20] x26: 0400 x27: 0002
[2021-11-17 13:49:20] x28: x29: faee06b0
[2021-11-17 13:49:20]
2021年10月22日(金) 22:47 Marek Behún :
>
> From: Marek Behún
>
> This board sets gd->env_addr to default_environment in board_init(), but
> the board has environment in SPI flash according to defconfig. Let the
> env API handle environment automatically.
>
> Signed-off-by: Marek Behún
> Cc: Masami Hiramatsu
> ---
> board/socionext/developerbox/developerbox.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/board/socionext/developerbox/developerbox.c
> b/board/socionext/developerbox/developerbox.c
> index 9552bfcdc3..31b1349514 100644
> --- a/board/socionext/developerbox/developerbox.c
> +++ b/board/socionext/developerbox/developerbox.c
> @@ -82,8 +82,6 @@ int board_init(void)
> {
> gd->bd->bi_boot_params = CONFIG_SYS_LOAD_ADDR + LOAD_OFFSET;
>
> - gd->env_addr = (ulong)_environment[0];
> -
> synquacer_setup_scbm_smmu();
>
> return 0;
> --
> 2.32.0
>
--
Masami Hiramatsu
RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS
Hi Ramon,
> -Original Message-
> From: Ramon Fried
> Sent: 2021年11月17日 12:20
> To: Joakim Zhang
> Cc: Joe Hershberger ; U-Boot Mailing List
> ; Ye Li ; Patrick Delaunay
> ; Daniil Stas ;
> Stephen Warren
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
>
> On Tue, Nov 16, 2021 at 1:02 PM Joakim Zhang
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ramon Fried
> > > Sent: 2021年11月16日 18:45
> > > To: Joakim Zhang
> > > Cc: Joe Hershberger ; U-Boot Mailing List
> > > ; Ye Li ; Patrick Delaunay
> > > ; Daniil Stas
> > > ; Stephen Warren
> > > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe
> > > stage instead of starting EQOS
> > >
> > > On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang
> > >
> > > wrote:
> > > >
> > > >
> > > > Hi Ramon,
> > > >
> > > > > -Original Message-
> > > > > From: Ramon Fried
> > > > > Sent: 2021年11月16日 13:57
> > > > > To: Joakim Zhang
> > > > > Cc: Joe Hershberger ; U-Boot Mailing
> > > > > List ; Ye Li ; Patrick
> > > > > Delaunay ; Daniil Stas
> > > > > ; Stephen Warren
> > > > > Subject: Re: [PATCH] net: eqos: connect and config PHY from
> > > > > probe stage instead of starting EQOS
> > > > >
> > > > > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > For EQOS ethernet, it will do phy_connect() and phy_config()
> > > > > > when start the ethernet (eqos_srart()), users need wait
> > > > > > seconds for PHY auto negotiation to complete when do tftp boot.
> > > > > > phy_config()
> > > > > > -> board_phy_config()
> > > > > > -> phydev->drv->config() // i.MX8MP/DXL
> > > > > > use
> > > > > realtek PHY
> > > > > > -> rtl8211f_config()
> > > > > > -> genphy_config_aneg()
> > > > > > ->
> > > > > genphy_restart_aneg()
> > > > > > // restart auto-nego, then need seconds to complete
> > > > > >
> > > > > > To avoid wasting time, we can move PHY connection and
> > > > > > configuration from
> > > > > > eqos_start() to eqos_probe(). This patch also moves clock
> > > > > > setting from
> > > > > > eqos_start() to eqos_probe() as MDIO access need CSR clock,
> > > > > > there is no function change.
> > > > > >
> > > > > > Tested-on: i.MX8MP & i.MX8DXL
> > > > > >
> > > > > > Before:
> > > > > > u-boot=> run netboot
> > > > > > Booting from net ...
> > > > > > ethernet@30bf Waiting for PHY auto negotiation to
> complete...
> > > > > > done BOOTP broadcast 1 DHCP client bound to address
> > > > > > 10.193.102.192
> > > > > > (313 ms) Using ethernet@30bf device TFTP from server
> > > > > > 10.193.108.176; our IP address is 10.193.102.192; sending
> > > > > > through gateway 10.193.102.254
> > > > > > After:
> > > > > > u-boot=> run netboot
> > > > > > Booting from net ...
> > > > > > BOOTP broadcast 1
> > > > > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > > > > ethernet@30bf device TFTP from server 10.193.108.176; our
> > > > > > IP address is 10.193.102.192; sending through gateway
> > > > > > 10.193.102.254
> > > > > >
> > > > > How much time do you save exactly, Is it the ~140ms you show
> > > > > here at the commit log ?
> > > >
> > > > Exactly not. This time points to DHCP client bound to address, not
> > > > the time
> > > this patch saves.
> > > >
> > > > How can we evaluate the time we save? Please see the log:
> > > >
> > > > Before:
> > > > Booting from net ...
> > > > ethernet@30bf Waiting for PHY auto negotiation to
> complete...
> > > done
> > > > BOOTP broadcast 1
> > > > After:
> > > > Booting from net ...
> > > > BOOTP broadcast 1
> > > >
> > > > And you need to check the related code:
> > > > drivers/net/dwc_eth_qos.c: phy_startup ->...->
> > > > drivers/net/phy/phy.c: genphy_update_link()
> > > >
> > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fso
> > > ur
> > > >
> > >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> > > %2Fphy
> > > > %2Fphy.c%23L225data=04%7C01%7Cqiangqing.zhang%40nxp.co
> m%
> > > 7C59322db
> > > >
> > >
> 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > > 7C0%7
> > > >
> > >
> C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > > MDAiLCJQIj
> > > >
> > >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=usRIR7L
> > > exBnk
> > > > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3Dreserved=0
> > > >
> > > > while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> > > > /*
> > > > * Timeout reached ?
> > > > */
> > > > if (i > (PHY_ANEG_TIMEOUT / 50)) {
> > > > printf(" TIMEOUT !\n");
> > > > phydev->link = 0;
> > > > return
Re: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS
On Tue, Nov 16, 2021 at 1:02 PM Joakim Zhang wrote:
>
>
> > -Original Message-
> > From: Ramon Fried
> > Sent: 2021年11月16日 18:45
> > To: Joakim Zhang
> > Cc: Joe Hershberger ; U-Boot Mailing List
> > ; Ye Li ; Patrick Delaunay
> > ; Daniil Stas ;
> > Stephen Warren
> > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> > instead of starting EQOS
> >
> > On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang
> > wrote:
> > >
> > >
> > > Hi Ramon,
> > >
> > > > -Original Message-
> > > > From: Ramon Fried
> > > > Sent: 2021年11月16日 13:57
> > > > To: Joakim Zhang
> > > > Cc: Joe Hershberger ; U-Boot Mailing List
> > > > ; Ye Li ; Patrick Delaunay
> > > > ; Daniil Stas
> > > > ; Stephen Warren
> > > > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe
> > > > stage instead of starting EQOS
> > > >
> > > > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> > > >
> > > > wrote:
> > > > >
> > > > > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > > > > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > > > > auto negotiation to complete when do tftp boot.
> > > > > phy_config()
> > > > > -> board_phy_config()
> > > > > -> phydev->drv->config() // i.MX8MP/DXL use
> > > > realtek PHY
> > > > > -> rtl8211f_config()
> > > > > -> genphy_config_aneg()
> > > > > ->
> > > > genphy_restart_aneg()
> > > > > // restart auto-nego, then need seconds to complete
> > > > >
> > > > > To avoid wasting time, we can move PHY connection and
> > > > > configuration from
> > > > > eqos_start() to eqos_probe(). This patch also moves clock setting
> > > > > from
> > > > > eqos_start() to eqos_probe() as MDIO access need CSR clock, there
> > > > > is no function change.
> > > > >
> > > > > Tested-on: i.MX8MP & i.MX8DXL
> > > > >
> > > > > Before:
> > > > > u-boot=> run netboot
> > > > > Booting from net ...
> > > > > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > > > > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > > > > (313 ms) Using ethernet@30bf device TFTP from server
> > > > > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > > > > gateway 10.193.102.254
> > > > > After:
> > > > > u-boot=> run netboot
> > > > > Booting from net ...
> > > > > BOOTP broadcast 1
> > > > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > > > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > > > > address is 10.193.102.192; sending through gateway 10.193.102.254
> > > > >
> > > > How much time do you save exactly, Is it the ~140ms you show here at
> > > > the commit log ?
> > >
> > > Exactly not. This time points to DHCP client bound to address, not the
> > > time
> > this patch saves.
> > >
> > > How can we evaluate the time we save? Please see the log:
> > >
> > > Before:
> > > Booting from net ...
> > > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > done
> > > BOOTP broadcast 1
> > > After:
> > > Booting from net ...
> > > BOOTP broadcast 1
> > >
> > > And you need to check the related code:
> > > drivers/net/dwc_eth_qos.c: phy_startup ->...->
> > > drivers/net/phy/phy.c: genphy_update_link()
> > >
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> > >
> > ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> > %2Fphy
> > > %2Fphy.c%23L225data=04%7C01%7Cqiangqing.zhang%40nxp.com%
> > 7C59322db
> > >
> > 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7
> > >
> > C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > MDAiLCJQIj
> > >
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=usRIR7L
> > exBnk
> > > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3Dreserved=0
> > >
> > > while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> > > /*
> > > * Timeout reached ?
> > > */
> > > if (i > (PHY_ANEG_TIMEOUT / 50)) {
> > > printf(" TIMEOUT !\n");
> > > phydev->link = 0;
> > > return -ETIMEDOUT;
> > > }
> > >
> > > if (ctrlc()) {
> > > puts("user interrupt!\n");
> > > phydev->link = 0;
> > > return -EINTR;
> > > }
> > >
> > > if ((i++ % 10) == 0)
> > > printf(".");
> > >
> > > mii_reg = phy_read(phydev,
> > MDIO_DEVAD_NONE, MII_BMSR);
> > > mdelay(50); /* 50 ms */
> > > }
> > >
> > > We can see that one "." is about
U-Boot CPU clock slower than it is in OS?
I’m doing some development on an AM335x ARM CPU and want to run applications in the U-Boot command prompt. My problem: the code is much slower in U-Boot than it is in Linux. I was wondering if U-Boot is able to set clock settings and if there's a way that I can tweak them to improve performance of programs that run from the U-Boot command prompt. Kyle
Re: [RFC PATCH] RFC: Sketch of dm event notification
On Tue, Nov 16, 2021 at 07:48:59PM -0700, Simon Glass wrote: > Hi Takahiro, > > On Tue, 16 Nov 2021 at 19:31, AKASHI Takahiro > wrote: > > > > Simon, > > > > On Mon, Nov 01, 2021 at 03:41:50PM +0900, AKASHI Takahiro wrote: > > > Hello Simon, > > > > > > On Sun, Oct 31, 2021 at 09:07:01PM -0600, Simon Glass wrote: > > > > This is a patch for Takahiro to look at, just for illustration. Not > > > > ready > > > > for review. > > > > > > Thank you for posting the draft. > > > At a first glance, it looks good and I don't see any specific issue > > > with your implementation. > > > > I said OK and functionally it should work well, but I now have > > some concerns: > > 1) In my current implementation, I use post_probe/pre_remove hooks > >of BLK device to invoke efi callback functions. In this sense, > >event(POST_PROBE/ PRE_REMOVE) seems to be a duplicated feature > >in some way. > > We should not be calling EFI functions from a BLK devince, unless it > is an EFI block device, i.e. we should provide hooks for EFI or any > other interested party to use. Even for now, part_init() is called in post_probe() (and blk_create_partitions(), which is to create another type of uclass device, in my patch as well). So I'm not sure what functions can and should be called and what not in those hooks. Do you want to convert part_init() to an event subscriber along with my efi hooks? -Takahiro Akashi > > 2) For the rest of uclass devices which don't utilise events yet, > >device_notify() is nothing but an overhead as it always tries to > >go through a list of event hooks. > > Yes that's true, but it can be optimised to avoid useless > searches/calls, since subscribers need to specify an even they are > interested in. > > > > > Event notification can be more than just a dm feature, but ... > > What's your thought here? > > Yes, more than just a DM feature. For example I think it could help > with the initcalls we have in board_f and board_r. > > Regards, > Simon > > > > > -Takahiro Akashi > > > > > Since my code has already added DM_TAG support, I'm looking forward for > > > getting your final patch. > > > > > > The only remaining issue is *modeling* partitions :) > > > > > > -Takahiro Akashi > > > > > > > To run the test: > > > > > > > > ./u-boot -T -c "ut common test_event_probe" > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > [..] > > Regards, > Simon
[PATCH V3] sf: Querying write-protect status before operating the flash
From: chao zeng
When operating the write-protection flash,spi_flash_std_write() and
spi_flash_std_erase() would return wrong result.The flash is protected,
but write or erase the flash would show "OK".
Check the flash write protection state before operating the flash
and give a prompt to show it has been locked if the write-protection
has enbale
Signed-off-by: chao zeng
---
Changes for V2:
- Return 0 not ENOPROTOOPT to refelect the flash feature
- Output prompt information
Changes for V3:
- Modify output information
- Delete return statement
---
drivers/mtd/spi/sf_probe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index f461082e03..f9e879aec5 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -109,6 +109,9 @@ static int spi_flash_std_write(struct udevice *dev, u32
offset, size_t len,
struct mtd_info *mtd = >mtd;
size_t retlen;
+ if (flash->flash_is_locked && flash->flash_is_locked(flash, offset,
len))
+ printf("SF: Operate on the protected area.Writes will be
ignored\n");
+
return mtd->_write(mtd, offset, len, , buf);
}
@@ -127,6 +130,9 @@ static int spi_flash_std_erase(struct udevice *dev, u32
offset, size_t len)
instr.addr = offset;
instr.len = len;
+ if (flash->flash_is_locked && flash->flash_is_locked(flash, offset,
len))
+ printf("SF: Operate on the protected area.Erase will be
ignored\n");
+
return mtd->_erase(mtd, );
}
--
2.33.1
Re: [RFC PATCH] RFC: Sketch of dm event notification
Hi Takahiro, On Tue, 16 Nov 2021 at 19:31, AKASHI Takahiro wrote: > > Simon, > > On Mon, Nov 01, 2021 at 03:41:50PM +0900, AKASHI Takahiro wrote: > > Hello Simon, > > > > On Sun, Oct 31, 2021 at 09:07:01PM -0600, Simon Glass wrote: > > > This is a patch for Takahiro to look at, just for illustration. Not ready > > > for review. > > > > Thank you for posting the draft. > > At a first glance, it looks good and I don't see any specific issue > > with your implementation. > > I said OK and functionally it should work well, but I now have > some concerns: > 1) In my current implementation, I use post_probe/pre_remove hooks >of BLK device to invoke efi callback functions. In this sense, >event(POST_PROBE/ PRE_REMOVE) seems to be a duplicated feature >in some way. We should not be calling EFI functions from a BLK devince, unless it is an EFI block device, i.e. we should provide hooks for EFI or any other interested party to use. > 2) For the rest of uclass devices which don't utilise events yet, >device_notify() is nothing but an overhead as it always tries to >go through a list of event hooks. Yes that's true, but it can be optimised to avoid useless searches/calls, since subscribers need to specify an even they are interested in. > > Event notification can be more than just a dm feature, but ... > What's your thought here? Yes, more than just a DM feature. For example I think it could help with the initcalls we have in board_f and board_r. Regards, Simon > > -Takahiro Akashi > > > Since my code has already added DM_TAG support, I'm looking forward for > > getting your final patch. > > > > The only remaining issue is *modeling* partitions :) > > > > -Takahiro Akashi > > > > > To run the test: > > > > > > ./u-boot -T -c "ut common test_event_probe" > > > > > > Signed-off-by: Simon Glass > > > --- [..] Regards, Simon
Re: [PATCH v2 1/1] tpm: clear state post probing
Hi Heinrich,
On Tue, 16 Nov 2021 at 04:08, Ilias Apalodimas
wrote:
>
> On Mon, Nov 15, 2021 at 08:30:06PM +0100, Heinrich Schuchardt wrote:
> > Before we can start measuring the TPM must be cleared. Do this in the
> > post_probe() method of the uclass.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > v2:
> > tpm_startup2() is not available on all boards.
> > tpm_startup() takes care of translating the call.
> > ---
> > drivers/tpm/tpm-uclass.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
> > index f67fe1019b..abd9ce35e8 100644
> > --- a/drivers/tpm/tpm-uclass.c
> > +++ b/drivers/tpm/tpm-uclass.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "tpm_internal.h"
> > @@ -136,6 +137,17 @@ int tpm_xfer(struct udevice *dev, const uint8_t
> > *sendbuf, size_t send_size,
> > return 0;
> > }
> >
> > +static int dm_tpm_post_probe(struct udevice *dev)
Please drop the dm_
> > +{
> > + /*
> > + * Clearing the TPM state is only possible once after a hard reset.
> > + * As we do not know if the TPM has been cleared by a prior boot stage
> > + * ignore the return value here.
> > + */
> > + tpm_startup(dev, TPM_ST_CLEAR);
blank line before final return
> > + return 0;
> > +}
This should only happen once and if the TPM is set up in SPL then this
seems to cause a failure if done again.
Is there another way we can deal with this? Could the TPM user decide
whether it needs to be set?
For the approach you have here, I think the best option might be to
add a property to the devicetree. That way the prior stage can control
it.
> > +
> > UCLASS_DRIVER(tpm) = {
> > .id = UCLASS_TPM,
> > .name = "tpm",
> > @@ -143,5 +155,6 @@ UCLASS_DRIVER(tpm) = {
> > #if CONFIG_IS_ENABLED(OF_REAL)
> > .post_bind = dm_scan_fdt_dev,
> > #endif
> > + .post_probe = dm_tpm_post_probe,
> > .per_device_auto= sizeof(struct tpm_chip_priv),
> > };
> > --
> > 2.32.0
> >
>
> Reviewed-by: Ilias Apalodimas
Regards,
Simon
Re: [PATCH 1/1] test: test truncation in snprintf()
On Mon, 15 Nov 2021 at 11:07, Heinrich Schuchardt wrote: > > Test that the return value of snprintf() is correct in the case of > truncation. > > Signed-off-by: Heinrich Schuchardt > --- > test/print_ut.c | 18 ++ > 1 file changed, 18 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 1/1] doc: fix typos in trace.rst
Hi Heinrich, On Tue, 16 Nov 2021 at 10:59, Heinrich Schuchardt wrote: > > Fix obvious typos. Use US spelling consistently. Typos are good to fix but we should accept English spelling. Regards, Simon > > Signed-off-by: Heinrich Schuchardt > --- > doc/develop/trace.rst | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst > index 7776c48428..09f5745a90 100644 > --- a/doc/develop/trace.rst > +++ b/doc/develop/trace.rst > @@ -4,7 +4,7 @@ > Tracing in U-Boot > = > > -U-Boot supports a simple tracing feature which allows a record of excecution > +U-Boot supports a simple tracing feature which allows a record of execution > to be collected and sent to a host machine for analysis. At present the > main use for this is to profile boot time. > > @@ -161,10 +161,10 @@ limit of the trace buffer size you have specified. Once > that is exhausted > no more data will be collected. > > Collecting trace data has an affect on execution time/performance. You > -will notice this particularly with trvial functions - the overhead of > +will notice this particularly with trivial functions - the overhead of > recording their execution may even exceed their normal execution time. > In practice this doesn't matter much so long as you are aware of the > -effect. Once you have done your optimisations, turn off tracing before > +effect. Once you have done your optimizations, turn off tracing before > doing end-to-end timing. > > The best time to start tracing is right at the beginning of U-Boot. The > @@ -184,7 +184,7 @@ the OS. In practical terms, U-Boot runs the 'fakegocmd' > environment > variable at this point. This variable should have a short script which > collects the trace data and writes it somewhere. > > -Trace data collection relies on a microsecond timer, accesed through > +Trace data collection relies on a microsecond timer, accessed through > timer_get_us(). So the first think you should do is make sure that > this produces sensible results for your board. Suitable sources for > this timer include high resolution timers, PWMs or profile timers if > @@ -285,7 +285,7 @@ Options > Specify U-Boot map file > > -p > -Specifiy profile/trace file > +Specify profile/trace file > > Commands: > > @@ -315,11 +315,11 @@ time: > 2. Build U-Boot with tracing and run it. Note the difference in boot time > (it is common for tracing to add 10% to the time) > > -3. Collect the trace information as descibed above. Use this to find where > +3. Collect the trace information as described above. Use this to find where > all the time is being spent. > > -4. Take a look at that code and see if you can optimise it. Perhaps it is > - possible to speed up the initialisation of a device, or remove an unused > +4. Take a look at that code and see if you can optimize it. Perhaps it is > + possible to speed up the initialization of a device, or remove an unused > feature. > > 5. Rebuild, run and collect again. Compare your results. > -- > 2.32.0 >
Re: [PATCH 04/10] Convert CONFIG_PHYSMEM to Kconfig
Hi Heinrich, On Sun, 14 Nov 2021 at 02:46, Heinrich Schuchardt wrote: > > On 11/14/21 04:21, Simon Glass wrote: > > This converts the following to Kconfig: > > CONFIG_PHYSMEM > > > > Signed-off-by: Simon Glass > > --- > > > > README | 8 > > arch/Kconfig | 2 ++ > > include/configs/edison.h | 3 --- > > include/configs/sandbox.h| 2 -- > > include/configs/x86-common.h | 2 -- > > lib/Kconfig | 10 ++ > > scripts/config_whitelist.txt | 1 - > > 7 files changed, 12 insertions(+), 16 deletions(-) > > > > diff --git a/README b/README > > index 9606a8b3acf..70485e7fb9f 100644 > > --- a/README > > +++ b/README > > @@ -1716,14 +1716,6 @@ The following options need to be configured: > > HERMES, IP860, RPXlite, LWMON, > > FLAGADM > > > > -- Access to physical memory region (> 4GB) > > - Some basic support is provided for operations on memory not > > - normally accessible to U-Boot - e.g. some architectures > > - support access to more than 4GB of memory on 32-bit > > - machines using physical address extension or similar. > > - Define CONFIG_PHYSMEM to access this basic support, which > > - currently only supports clearing the memory. > > - > > - Error Recovery: > > CONFIG_NET_RETRY_COUNT > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > index 3e2cc84ab2c..1e0e6118139 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -194,6 +194,7 @@ config SANDBOX > > imply PHY_FIXED > > imply DM_DSA > > imply CMD_EXTENSION > > + imply PHYSMEM > > > > config SH > > bool "SuperH architecture" > > @@ -245,6 +246,7 @@ config X86 > > imply USB_ETHER_SMSC95XX > > imply USB_HOST_ETHER > > imply PCH > > + imply PHYSMEM > > imply RTC_MC146818 > > imply ACPIGEN if !QEMU > > imply SYSINFO if GENERATE_SMBIOS_TABLE > > diff --git a/include/configs/edison.h b/include/configs/edison.h > > index 3ec35db4bcf..02f33f3c29f 100644 > > --- a/include/configs/edison.h > > +++ b/include/configs/edison.h > > @@ -14,9 +14,6 @@ > > #define CONFIG_SYS_MAXARGS 128 > > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > > > > -/* Memory */ > > -#define CONFIG_PHYSMEM > > - > > #define CONFIG_SYS_STACK_SIZE (32 * 1024) > > > > #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE > > diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h > > index 09f46ca1ac2..48cae7d972a 100644 > > --- a/include/configs/sandbox.h > > +++ b/include/configs/sandbox.h > > @@ -18,8 +18,6 @@ > > > > #define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */ > > > > -#define CONFIG_PHYSMEM > > - > > /* Size of our emulated memory */ > > #define SB_CONCAT(x, y) x ## y > > #define SB_TO_UL(s) SB_CONCAT(s, UL) > > diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h > > index 486b5ca7765..33209fad4fc 100644 > > --- a/include/configs/x86-common.h > > +++ b/include/configs/x86-common.h > > @@ -14,8 +14,6 @@ > >* High Level Configuration Options > >* (easy to change) > >*/ > > -#define CONFIG_PHYSMEM > > - > > #define CONFIG_SYS_BOOTM_LEN(16 << 20) > > > > /* SATA AHCI storage */ > > diff --git a/lib/Kconfig b/lib/Kconfig > > index 70bf8e7a464..f3baf45718e 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -15,6 +15,16 @@ config SYS_NUM_ADDR_MAP > > help > > Sets the number of entries in the virtual-physical mapping table. > > > > +config PHYSMEM > > + bool "Access to physical memory region (> 4GB)" > > %s/4GB/4 GiB/ Please let's not add that junk to U-Boot. > > > + help > > + Some basic support is provided for operations on memory not > > + normally accessible to 32-bit U-Boot - e.g. some architectures > > + support access to more than 4GB of memory on 32-bit > > + machines using physical address extension or similar. > > You could simply drop all those lines and simply say say: > > "Clear memory above 4GiB on 32bit systems." > > But do we need this option at all? Why should this memory be cleared? > > Let's drop arch/x86/lib/physmem.c instead. It is only used by the Edison > board which is out of production since 2017. And that board only had 1 > GiB of memory (sic!). This option is used by Chrome OS vboot so I don't want to drop it. Regards, Simon
Re: [PATCH 01/10] trace: sandbox: Use only the Kconfig options
Hi Heinrich, On Sun, 14 Nov 2021 at 02:32, Heinrich Schuchardt wrote: > > On 11/14/21 04:21, Simon Glass wrote: > > At present there are Kconfig options for tracing, but sandbox uses > > plain #defines to set them. Correct this and make the tracing command > > default to enabled so that this is not needed. > > > > Signed-off-by: Simon Glass > > --- > > > > cmd/Kconfig | 2 ++ > > doc/develop/trace.rst | 14 +++--- > > 2 files changed, 9 insertions(+), 7 deletions(-) > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig > > index 5b30b13e438..fd8f0227c89 100644 > > --- a/cmd/Kconfig > > +++ b/cmd/Kconfig > > @@ -2350,6 +2350,8 @@ config CMD_LOG > > > > config CMD_TRACE > > bool "trace - Support tracing of function calls and timing" > > + depends on TRACE > > + default y > > help > > Enables a command to control using of function tracing within > > U-Boot. This allows recording of call traces including timing > > diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst > > index 7776c484286..34bce5d4677 100644 > > --- a/doc/develop/trace.rst > > +++ b/doc/develop/trace.rst > > @@ -30,16 +30,16 @@ Sandbox is a build of U-Boot that can run under Linux > > so it is a convenient > > way of trying out tracing before you use it on your actual board. To do > > this, follow these steps: > > > > -Add the following to include/configs/sandbox.h (if not already there) > > +Add the following to config/sandbox_defconfig (if not already there) > > > > .. code-block:: c > > > > -#define CONFIG_TRACE > > -#define CONFIG_CMD_TRACE > > -#define CONFIG_TRACE_BUFFER_SIZE(16 << 20) > > -#define CONFIG_TRACE_EARLY_SIZE (8 << 20) > > -#define CONFIG_TRACE_EARLY > > -#define CONFIG_TRACE_EARLY_ADDR 0x0010 > > +CONFIG_TRACE=y > > +CONFIG_TRACE_BUFFER_SIZE=0x0100 > > +CONFIG_TRACE_BUFFER_SIZE=0x0100 > > This line is duplicate. And it is anyway the default value in > lib/Kconfig:229. So both lines can be removed. > > > +CONFIG_TRACE_EARLY_SIZE=0x80 > > Is the CONFIG_TRACE_EARLY default inadequate and should be changed? Yes it is helpful to have it a lot larger for sandbox. > > > > +CONFIG_TRACE_EARLY=y > > +CONFIG_TRACE_EARLY_ADDR=0x0010 > > This is the default value. The line can be removed. Right, but this is documentation, so I think it is important to have everything in there, isn't it? Regards, Simon
Re: [RFC PATCH] RFC: Sketch of dm event notification
Simon,
On Mon, Nov 01, 2021 at 03:41:50PM +0900, AKASHI Takahiro wrote:
> Hello Simon,
>
> On Sun, Oct 31, 2021 at 09:07:01PM -0600, Simon Glass wrote:
> > This is a patch for Takahiro to look at, just for illustration. Not ready
> > for review.
>
> Thank you for posting the draft.
> At a first glance, it looks good and I don't see any specific issue
> with your implementation.
I said OK and functionally it should work well, but I now have
some concerns:
1) In my current implementation, I use post_probe/pre_remove hooks
of BLK device to invoke efi callback functions. In this sense,
event(POST_PROBE/ PRE_REMOVE) seems to be a duplicated feature
in some way.
2) For the rest of uclass devices which don't utilise events yet,
device_notify() is nothing but an overhead as it always tries to
go through a list of event hooks.
Event notification can be more than just a dm feature, but ...
What's your thought here?
-Takahiro Akashi
> Since my code has already added DM_TAG support, I'm looking forward for
> getting your final patch.
>
> The only remaining issue is *modeling* partitions :)
>
> -Takahiro Akashi
>
> > To run the test:
> >
> > ./u-boot -T -c "ut common test_event_probe"
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > common/Kconfig| 11
> > common/Makefile | 2 +
> > common/board_f.c | 2 +
> > common/event.c| 103 ++
> > common/log.c | 1 +
> > drivers/core/device.c | 14
> > include/asm-generic/global_data.h | 3 +
> > include/event.h | 103 ++
> > include/event_internal.h | 34 ++
> > include/log.h | 2 +
> > test/common/Makefile | 1 +
> > test/common/event.c | 85
> > test/test-main.c | 5 ++
> > 13 files changed, 366 insertions(+)
> > create mode 100644 common/event.c
> > create mode 100644 include/event.h
> > create mode 100644 include/event_internal.h
> > create mode 100644 test/common/event.c
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index d6f77ab7b9c..54d0adaa8d5 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -484,6 +484,17 @@ config DISPLAY_BOARDINFO_LATE
> >
> > menu "Start-up hooks"
> >
> > +config EVENT
> > + bool "General-purpose event-handling mechanism"
> > + default y if SANDBOX
> > + help
> > + This enables sending and processing of events, to allow interested
> > + parties to be alerted when something happens. This is an attempt to
> > + step the flow of weak functions, hooks, functions in board_f.c
> > + and board_r.c and the Kconfig options below.
> > +
> > + See doc/develop/event.rst for more information.
> > +
> > config ARCH_EARLY_INIT_R
> > bool "Call arch-specific init soon after relocation"
> > help
> > diff --git a/common/Makefile b/common/Makefile
> > index e7839027b6c..1b4601ac13f 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -101,6 +101,8 @@ obj-y += malloc_simple.o
> > endif
> > endif
> >
> > +obj-$(CONFIG_EVENT) += event.o
> > +
> > obj-y += image.o image-board.o
> > obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
> > obj-$(CONFIG_ANDROID_AB) += android_ab.o
> > diff --git a/common/board_f.c b/common/board_f.c
> > index 3dc0eaa59c5..faf262d564c 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -820,6 +821,7 @@ static const init_fnc_t init_sequence_f[] = {
> > initf_malloc,
> > log_init,
> > initf_bootstage,/* uses its own timer, so does not need DM */
> > + event_init,
> > #ifdef CONFIG_BLOBLIST
> > bloblist_init,
> > #endif
> > diff --git a/common/event.c b/common/event.c
> > new file mode 100644
> > index 000..428628da44d
> > --- /dev/null
> > +++ b/common/event.c
> > @@ -0,0 +1,103 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Events provide a general-purpose way to react to / subscribe to changes
> > + * within U-Boot
> > + *
> > + * Copyright 2021 Google LLC
> > + * Written by Simon Glass
> > + */
> > +
> > +#define LOG_CATEGORY LOGC_EVENT
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static void spy_free(struct event_spy *spy)
> > +{
> > + list_del(>sibling_node);
> > +}
> > +
> > +int event_register(const char *id, enum event_t type, event_handler_t
> > func, void *ctx)
> > +{
> > + struct event_state *state = gd->event_state;
> > + struct event_spy *spy;
> > +
> > + spy = malloc(sizeof(*spy));
> > + if (!spy)
> > + return log_msg_ret("alloc", -ENOMEM);
> > +
> > + spy->id = id;
> > +
Re: [PATCH v10 1/9] sandbox: Drop distro_boot
On Thu, Oct 21, 2021 at 09:08:44PM -0600, Simon Glass wrote: > This is a complicated set of #defines and it is painful to convert to a > text file. We can (once pending patches are applied) provide the same > functionality with bootmethod. Drop this for sandbox to allow conversion > to a text-file environment. > > Signed-off-by: Simon Glass > Reviewed-by: Marek Behún For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 01/12] tools: mkeficapsule: rework the code a little bit
On Tue, Nov 16, 2021 at 01:19:10PM +0100, Heinrich Schuchardt wrote:
> On 11/16/21 05:32, AKASHI Takahiro wrote:
> > Abstract common routines to make the code easily understandable.
> > No functional change.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > ---
> > tools/mkeficapsule.c | 223 ++-
> > 1 file changed, 159 insertions(+), 64 deletions(-)
> >
> > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > index 4995ba4e0c2a..afdcaf7e7933 100644
> > --- a/tools/mkeficapsule.c
> > +++ b/tools/mkeficapsule.c
> > @@ -61,17 +61,122 @@ static void print_usage(void)
> >tool_name);
> > }
> >
> > +/**
> > + * read_bin_file - read a firmware binary file
> > + * @bin: Path to a firmware binary file
> > + * @data: Pointer to pointer of allocated buffer
> > + * @bin_size: Size of allocated buffer
> > + *
> > + * Read out a content of binary, @bin, into @data.
> > + * A caller should free @data.
> > + *
> > + * Return:
> > + * * 0 - on success
> > + * * -1 - on failure
> > + */
> > +static int read_bin_file(char *bin, void **data, off_t *bin_size)
> > +{
> > + FILE *g;
> > + struct stat bin_stat;
> > + void *buf;
> > + size_t size;
> > + int ret = 0;
> > +
> > + g = fopen(bin, "r");
> > + if (!g) {
> > + printf("cannot open %s\n", bin);
>
> Error messages should be written to stderr. Use perror(bin) to get a
> message like:
>
> : No such file or directory
>
> Or use fprintf(stderr, ...).
OK.
But remember that I have used printf() throughout mkeficapsule.c
even before this patch.
So I will add similar changes in patch#1 for consistency.
> > + return -1;
> > + }
> > + if (stat(bin, _stat) < 0) {
> > + printf("cannot determine the size of %s\n", bin);
> > + ret = -1;
> > + goto err;
> > + }
> > + if (bin_stat.st_size > (u32)~0U) {
> > + printf("file size is too large: %s\n", bin);
> > + ret = -1;
> > + goto err;
> > + }
> > + buf = malloc(bin_stat.st_size);
>
> For a symbolic link st_size is the length of the pathname it contains.
> So this function is of no help here.
Not true.
According to stat() manpage,
"lstat() is identical to stat(), except that if pathname is a symbolic
link, then it returns information about the link itself, not the file
that it refers to."
So stat() is a right system call.
> > + if (!buf) {
> > + printf("cannot allocate memory: %zx\n",
> > + (size_t)bin_stat.st_size);
> > + ret = -1;
> > + goto err;
> > + }
> > +
> > + size = fread(buf, 1, bin_stat.st_size, g);
> > + if (size < bin_stat.st_size) {
>
> fread() reads from a stream which is not necessarily a file but can be a
> named pipe. stat() does not indicate when the stream will end.
>
> You have to run fread() in a loop until feof() or ferror() indicate that
> there is nothing more to be read from the stream.
No.
"a stream which is not necessarily a file but can be a named pipe"
may be true, but we don't handle such a use case with this tool.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > + printf("read failed (%zx)\n", size);
> > + ret = -1;
> > + goto err;
> > + }
> > +
> > + *data = buf;
> > + *bin_size = bin_stat.st_size;
> > +err:
> > + fclose(g);
> > +
> > + return ret;
> > +}
> > +
> > +/**
> > + * write_capsule_file - write a capsule file
> > + * @bin: FILE stream
> > + * @data: Pointer to data
> > + * @bin_size: Size of data
> > + *
> > + * Write out data, @data, with the size @bin_size.
> > + *
> > + * Return:
> > + * * 0 - on success
> > + * * -1 - on failure
> > + */
> > +static int write_capsule_file(FILE *f, void *data, size_t size, const char
> > *msg)
> > +{
> > + size_t size_written;
> > +
> > + size_written = fwrite(data, 1, size, f);
> > + if (size_written < size) {
> > + printf("%s: write failed (%zx != %zx)\n", msg,
> > + size_written, size);
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * create_fwbin - create an uefi capsule file
> > + * @path: Path to a created capsule file
> > + * @bin: Path to a firmware binary to encapsulate
> > + * @guid: GUID of related FMP driver
> > + * @index: Index number in capsule
> > + * @instance: Instance number in capsule
> > + * @mcount:Monotonic count in authentication information
> > + * @private_file: Path to a private key file
> > + * @cert_file: Path to a certificate file
> > + *
> > + * This function actually does the job of creating an uefi capsule file.
> > + * All the arguments must be supplied.
> > + * If either @private_file ror @cert_file is NULL, the capsule file
> > + * won't be signed.
> > + *
> > + * Return:
> > + * * 0 - on success
> > + * * -1 - on failure
> > + */
> > static int create_fwbin(char *path, char *bin, efi_guid_t
Re: [PATCH v7 02/12] tools: build mkeficapsule with tools-only_defconfig
On Tue, Nov 16, 2021 at 02:58:39PM +0100, Heinrich Schuchardt wrote: > On 11/16/21 13:20, Heinrich Schuchardt wrote: > > On 11/16/21 05:32, AKASHI Takahiro wrote: > > > We want to always build mkeficapsule if tools-only_defconfig is used. > > > > > > Signed-off-by: AKASHI Takahiro > > > > Reviewed-by: Heinrich Schuchardt > > > > > --- > > > configs/tools-only_defconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig > > > index f482c9a1c1b0..5427797dd4c3 100644 > > > --- a/configs/tools-only_defconfig > > > +++ b/configs/tools-only_defconfig > > > @@ -31,3 +31,4 @@ CONFIG_I2C_EDID=y > > > # CONFIG_VIRTIO_MMIO is not set > > > # CONFIG_VIRTIO_PCI is not set > > > # CONFIG_VIRTIO_SANDBOX is not set > > > +CONFIG_TOOLS_MKEFICAPSULE=y > > > > > > You cannot use a symbol that is not yet defined. Please, swap patches 2 > and 3 when resubmitting. Instead of swapping, I will move the definition of TOOLS_MKEFICAPSULE from patch#3 to patch#2. That would clarify the intension. -Takahiro Akashi > Best regards > > Heinrich >
Re: [PATCH] efi_loader: fix FinalEvent table initial position
Hi Heinrich,
On Wed, 17 Nov 2021 at 01:24, Ilias Apalodimas
wrote:
>
> When initializing the final event table in create_final_event() we are
> setting the initial buffer position to sizeof(*final_event). Although
> we clear the buffer correctly and won't cause any problems, we should
> start logging events starting from zero.
> While at it add a cast when defining the final_event.
>
> Signed-off-by: Ilias Apalodimas
> ---
> lib/efi_loader/efi_tcg2.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index 189e4a5ba59c..634556342a7c 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -1257,10 +1257,11 @@ static efi_status_t create_final_event(void)
> goto out;
>
> memset(event_log.final_buffer, 0xff, TPM2_EVENT_LOG_SIZE);
> - final_event = event_log.final_buffer;
> + final_event =
> + (struct efi_tcg2_final_events_table *)event_log.final_buffer;
> final_event->number_of_events = 0;
> final_event->version = EFI_TCG2_FINAL_EVENTS_TABLE_VERSION;
> - event_log.final_pos = sizeof(*final_event);
> + event_log.final_pos = 0;
> ret = efi_install_configuration_table(_guid_final_events,
> final_event);
> if (ret != EFI_SUCCESS) {
> --
> 2.33.1
>
After sending this I just realized it's wrong. The current code is
correct, since we have to account for the number of events and version
Sorry for the noise
Cheers
/Ilias
[PATCH] efi_loader: fix FinalEvent table initial position
When initializing the final event table in create_final_event() we are
setting the initial buffer position to sizeof(*final_event). Although
we clear the buffer correctly and won't cause any problems, we should
start logging events starting from zero.
While at it add a cast when defining the final_event.
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_tcg2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 189e4a5ba59c..634556342a7c 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1257,10 +1257,11 @@ static efi_status_t create_final_event(void)
goto out;
memset(event_log.final_buffer, 0xff, TPM2_EVENT_LOG_SIZE);
- final_event = event_log.final_buffer;
+ final_event =
+ (struct efi_tcg2_final_events_table *)event_log.final_buffer;
final_event->number_of_events = 0;
final_event->version = EFI_TCG2_FINAL_EVENTS_TABLE_VERSION;
- event_log.final_pos = sizeof(*final_event);
+ event_log.final_pos = 0;
ret = efi_install_configuration_table(_guid_final_events,
final_event);
if (ret != EFI_SUCCESS) {
--
2.33.1
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > Hi Pali, > > > > While we are at it, this default should be changed in > > drivers/usb/host/Kconfig. > > > > config USB_XHCI_MVEBU > > bool "MVEBU USB 3.0 support" > > default y > > > > Setting this default correctly will save a couple Kbytes for other boards. > > default y if ARCH_MVEBU > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > "default y if ARCH_MVEBU" is same as "default y". Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest master tree. I'm switching back and forth between the 2021.10 tag and master so I did not see this in the 2021.10 tree. Thanks, Tony > If you have mvebu board when mvebu xhci controller is unused, you can > disable this option and save some space. I see that other xhci drivers > have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > Hi Pali, > > While we are at it, this default should be changed in > drivers/usb/host/Kconfig. > > config USB_XHCI_MVEBU > bool "MVEBU USB 3.0 support" > default y > > Setting this default correctly will save a couple Kbytes for other boards. > default y if ARCH_MVEBU Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So "default y if ARCH_MVEBU" is same as "default y". If you have mvebu board when mvebu xhci controller is unused, you can disable this option and save some space. I see that other xhci drivers have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, While we are at it, this default should be changed in drivers/usb/host/Kconfig. config USB_XHCI_MVEBU bool "MVEBU USB 3.0 support" default y Setting this default correctly will save a couple Kbytes for other boards. default y if ARCH_MVEBU Thanks, Tony On Fri, Nov 12, 2021 at 3:24 PM Tony Dinh wrote: > > On Fri, Nov 12, 2021 at 2:42 PM Pali Rohár wrote: > > > > On Friday 12 November 2021 13:46:29 Tony Dinh wrote: > > > Hi Stefan & Pali, > > > > > > On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote: > > > > > > > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > > > > On 11/11/21 22:10, Pali Rohár wrote: > > > > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > > > > I've also tried mdelay(3000), just to be sure. The result was the > > > > > > > same > > > > > > > hang in 'usb start'. > > > > > > > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on > > > > > > mailing > > > > > > list. After they are merged I will prepare and send final PCI > > > > > > Kirkwood > > > > > > patch for testing. > > > > > > > > > > Chiming in a bit late in this discussion: > > > > > > > > > > Is an explicit call to pci_init() necessary in this Kirwood case? > > > > > IIRC, > > > > > the DM infrastructure should make sure that all device are probed - > > > > > but > > > > > only when really needed. So if you don't need PCI in the boot process > > > > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > > > > will be done always. Then there should be no need for the additional > > > > > "pci enum". > > > > > > > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > > > > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > > > > calling pci_init()). Based on tests (see discussion in this thread) it > > > > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > > > > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > > > > pci_init() manually from board_late_init() (which is called later than > > > > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > > > > I might be missing something - did not check in depth. > > > > > > I think this must be the problem. Sorry I've missed this: > > > > > > config USB_XHCI_MVEBU > > > bool "MVEBU USB 3.0 support" > > > default y > > > depends on ARCH_MVEBU > > > select DM_REGULATOR > > > help > > > Choose this option to add support for USB 3.0 driver on mvebu > > > SoCs, which includes Armada8K, Armada3700 and other Armada > > > family SoCs. > > > > This is used for native USB 3.0 controller in Marvell SoC (connected via > > serdes). > > > > But you wrote and sent pci output, that you have PCIe-based USB > > controller connected via PCIe. > > Ah, got it. > > Thanks, > Tony > > > > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" > > > and do some more testing. > > > > > > Thanks, > > > Tony > > > > > > > > > > > > > Thanks, > > > > > Stefan
Re: [PATCH 10/10] board: sl28: disable random MAC address generation
On Mon, Nov 15, 2021 at 11:45:51PM +0100, Michael Walle wrote: > Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set > enetaddr to a random value if not set and then pass the randomly > generated MAC address to linux. First, for clarity I'm not nak'ing this. I kind of would like to see a slight reword as I think some things aren't 100% correct, even if the "save random MAC to ethaddr environment variable" change goes in. For example, it's quite long standing that (dev|pdata)->enetaddr populates "mac-address" and "local-mac-address" and it seems in some older cases we only set the "local-mac-address" property. > This is bad for the following reasons: > (1) it makes it impossible for linux to detect this error > (2) linux won't trigger any fallback mechanism for the case where > it didn't find any valid MAC address This feels in some ways to be a limitation of the binding: https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet-controller.yaml And it reads like we really must be populating "mac-address" with that random one and while providing a blank "local-mac-address" would be a way to say we don't know the true device one, it seems that wouldn't be used / noticed? > (3) a saveenv will store this randomly generated MAC address in the > environment > > Probably, the user will also be unaware that something is wrong. He will > just get different MAC addresses on each reboot, asking himself why this > is the case. > > As this board usually have a serial port, the user can just fix this by > setting the MAC address manually in the environment. Also disable the > netconsole just in case, because it cannot be guaranteed that it will > work in any case. After all, this was just a convenience option, because > the bootloader - right now - doesn't have the ability to read the MAC > address, which is stored in the OTP. But it is far more important to > have a clear view of whats wrong with a board and that means we can no > longer use this Kconfig option. > > Signed-off-by: Michael Walle > --- > configs/kontron_sl28_defconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig > index af907175f1..7fb6bdbe82 100644 > --- a/configs/kontron_sl28_defconfig > +++ b/configs/kontron_sl28_defconfig > @@ -59,8 +59,6 @@ CONFIG_OF_LIST="" > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > -CONFIG_NET_RANDOM_ETHADDR=y > -CONFIG_NETCONSOLE=y > CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_SCSI_AHCI=y > CONFIG_SATA_CEVA=y Now, an alternate solution here would be to enable these two options still and write an ft_board_setup() with: ... if ethaddr is in the locally administered pool then fdt_delprop(... "mac-address"); fdt_delprop(... "local-mac-address"); And that should cause the kernel to fall through the cases to find out where to get the real MAC from. I'm not super happy with this at first, but I also don't see anything clever in the binding we can do. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] sf: Querying write-protect status before operating the flash
On Tue, Nov 16, 2021 at 04:41:46PM +0800, chaochao wrote:
>
> On 2021/11/15 22:02, Jagan Teki wrote:
> > On Mon, Nov 15, 2021 at 6:51 PM chaochao2021...@163.com
> > wrote:
> > >
> > > On 2021/11/15 13:57, tudor.amba...@microchip.com wrote:
> > >
> > > Hi,
> > >
> > > + Michael
> > >
> > > On 11/15/21 4:37 AM, chaochao2021...@163.com wrote:
> > >
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > From: chao zeng
> > >
> > > When operating the write-protection flash,spi_flash_std_write() and
> > > spi_flash_std_erase() would return wrong result.The flash is protected,
> > > but write or erase the flash would show "OK".
> > >
> > > Check the flash write protection state before operating the flash
> > > and give a prompt to show it has been locked if the write-protection
> > > has enbale
> > >
> > > Signed-off-by: chao zeng
> > >
> > > ---
> > >
> > > Changes for V2:
> > > - Return 0 not ENOPROTOOPT to refelect the flash feature
> > > - Output prompt information
> > > ---
> > > drivers/mtd/spi/sf_probe.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> > > index f461082e03..995801817d 100644
> > > --- a/drivers/mtd/spi/sf_probe.c
> > > +++ b/drivers/mtd/spi/sf_probe.c
> > > @@ -109,6 +109,11 @@ static int spi_flash_std_write(struct udevice *dev,
> > > u32 offset, size_t len,
> > > struct mtd_info *mtd = >mtd;
> > > size_t retlen;
> > >
> > > + if (flash->flash_is_locked && flash->flash_is_locked(flash,
> > > offset, len)) {
> > > + printf("SF: Flash is locked\n");
> > >
> > > I would use a debug message, it's a flash specific thing. Also, I would
> > > update
> > > a bit the message, something like
> > > "SF: Flash has protected areas in the requested length. Writes will be
> > > ignored on those."
> > >
> > > + return 0;
> > >
> > > Michael has suggested to drop this line. I agree with him, check the
> > > conversation
> > > on the previous email thread.
> > >
> > > Cheers,
> > > ta
> > >
> > > + }
> > > +
> > > return mtd->_write(mtd, offset, len, , buf);
> > > }
> > >
> > > @@ -127,6 +132,11 @@ static int spi_flash_std_erase(struct udevice *dev,
> > > u32 offset, size_t len)
> > > instr.addr = offset;
> > > instr.len = len;
> > >
> > > + if (flash->flash_is_locked && flash->flash_is_locked(flash,
> > > offset, len)) {
> > > + printf("SF: Flash is locked\n");
> > > + return 0;
> > > + }
> > > +
> > > return mtd->_erase(mtd, );
> > > }
> > >
> > > --
> > > 2.33.1
> > >
> > >
> > >
> > > the background is we like to use sf command to operate the flash under
> > > uboot shell,
> > >
> > > "sf erase" command still would show the prompt "erase ok" even though
> > > write-enable has enabled.
> > >
> > >
> > > So at the beginning I'd like to return an error ,so the sf operation
> > > would show "erase failed" when operating the write-enabled devices.
> > >
> > >
> > > I'm agree with only output information to prompt the user the operation
> > > unsuccessful.
> > >
> > > But It should explicitly give clear hints,so I suggest at here using
> > > printf not debug.
> >
> > We cannot encourage sf to show non operational prints like locked or
> > unlocked on command line. Just check the contents via read and compare
> > and understand whether flash is written properly, if not written
> > properly user has to debug on his own.
>
> I think it’s not user friendly at all. Using debug is not a problem for
> developers, but it is not so good for users who use the sf command.
Yes, I think I agree that this is the kind of information that since it
is easily available to us at run time should be printed to the user when
things fail. We don't document and expect people to start with running
"sf protect" to check the status of writing to a specific area nor do we
tell people that all writes should be read back and verified in the
normal case.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/3] cmd: add acmconsole command
Hello! On Tuesday 16 November 2021 20:05:07 Loic Poulain wrote: > Hi Pali, > > Sorry for the late reply, > > On Mon, 27 Sept 2021 at 22:04, Pali Rohár wrote: > > > > On Thursday 19 August 2021 13:13:06 Loic Poulain wrote: > > > This command allows to start CDC ACM function and redirect console > > > (stdin, stdout, stderr) to USB (acmconsole start). The console can > > > then be accessed through the USB host for debugging purpose. The > > > host can stop the session (acmconsole stop) to revert back console > > > to serial and unregister CDC ACM USB function. > > > > Hello! > > > > Could you rather implement this CDC ACM gadget in a way that calling > > 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this > > console redirect? Like it is supported for current usbtty or vga output > > code. > > > > Then this acmconsole command would not be needed at all. > > Yes, that would be good, but AFAIR I restricted this cdc_acm usage to > this command because we can't have fine grained control like e.g. > using cdc_acm as stdout only, when used, it should necessarily be > STDIN (at least). The reason is because of the single-tasking nature > of u-boot, and the fact that we need to poll the USB controller for > events via the 'usb_gadget_handle_interrupts()' function. There was already discussion that custom commands for activating drivers are against driver model design. See: https://lore.kernel.org/u-boot/20211026151742.42b0fcfa@thinkpad/ So I think that there should not be any driver specific command which just activates device (in this case console). > In our case > we simply do that in the getc() function, which is only called for > input consoles in the u-boot mainloop. This looks like a hack in the current implementation which seems that also misuse driver model design. At least this should be documented as this is limitation of functionality. > An alternative would be to have a u-boot API to register generic > callbacks to be executed in the mainloop, but this is probably a > different thread. I guess that this should be discussed, so some optimal solution for issue is chosen. Otherwise we will have there second implementation of "usbtty", which even would not provide all functionality as original "usbtty" code. > Also we could possibly live with this 'bug' and simply accept that > stdout-only configuration will be broken. > > Regards, > Loic
Re: [PATCH v5 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
On Tue, Nov 16, 2021 at 03:11:19PM -0300, Ariel D'Alessandro wrote: > Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: > > - 1GiB DDR4 RAM > - 16 GiB eMMC > - SD card > - Gigabit ethernet > - USBOTG1 peripheral - fastboot > > Signed-off-by: Ariel D'Alessandro Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] xilinx patches for v2022.01-rc3
On Tue, Nov 16, 2021 at 03:46:44PM +0100, Michal Simek wrote: > Hi Tom, > > Please pull these changes to your tree. CI loop doesn't show any issue with > these patches. > > Thanks, > Michal > > The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d: > > Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2022.01-rc3 > > for you to fetch changes up to 11c0255cd8a7177e2b714040efcfd51844cb5d8e: > > xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check (2021-11-15 15:59:33 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/1] usb: doc: Fix spelling issues in README.usb
On Fri, Nov 12, 2021 at 06:37:47PM +0300, Andy Shevchenko wrote: > Fix spelling issues in README.usb. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Fix bad memcpy.S str8w macro argument count
On Wed, Nov 10, 2021 at 03:04:40PM +0100, Pierre-Clément Tosi wrote:
> Remove the extra (empty) argument passed to str8w, causing the following
> error:
>
>:40:47: error: too many positional arguments
> str8w r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
> ^
>u-boot/arch/arm/lib/memcpy.S:240:5: note: while in macro instantiation
>17: forward_copy_shift pull=16 push=16
>^
>
> Note: no functional change intended.
>
> Fixes: d8834a1323af ("arm: Use optimized memcpy and memset from linux")
> Signed-off-by: Pierre-Clément Tosi
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [BUGFIX PATCH] configs: synquacer: Fix dfu_alt_info to use nor1
On Wed, Nov 10, 2021 at 09:40:07AM +0900, Masami Hiramatsu wrote:
> Fix dfu_alt_info to use nor1 instead of the device name.
> This reverts a part of commit 59bd18d4c4d7 ("configs: synquacer:
> Remove mtdparts settings and update DFU setting") because the
> commit a4f2d8341455 ("mtd: spi: nor: force mtd name to "nor%d"")
> changed the mtd device naming scheme to nor%d.
>
> Signed-off-by: Masami Hiramatsu
> Acked-by: Ilias Apalodimas
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] image: Explicitly declare do_bdinfo()
On Mon, Nov 08, 2021 at 09:03:38PM +0300, Andy Shevchenko wrote: > Compiler is not happy: > > common/image-board.c: In function ‘boot_get_kbd’: > common/image-board.c:902:17: warning: implicit declaration of function > ‘do_bdinfo’ [-Wimplicit-function-declaration] > 902 | do_bdinfo(NULL, 0, 0, NULL); > | ^ > > Move the forward declaration to a header. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] makefile: add missing semicolons
On Fri, Nov 05, 2021 at 04:20:24PM +0100, Angelo Dureghello wrote: > On some distributions, as Debian GNU 11, this targets fails > with errors. > > Signed-off-by: Angelo Dureghello Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] board: tq: fix spelling of "TQ-Systems"
On Tue, Nov 02, 2021 at 11:36:46AM +0100, Matthias Schiffer wrote: > "TQ-Systems" is written with a dash. > > Signed-off-by: Matthias Schiffer Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] board: rename "tqc" vendor to "tq"
On Tue, Nov 02, 2021 at 11:36:45AM +0100, Matthias Schiffer wrote: > The subdivision name "TQ Components" hasn't been in use for a long time. > Rename the vendor directory to "tq", which also matches our Device Tree > vendor prefix. > > Signed-off-by: Matthias Schiffer Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm64: relocate-rela: Add support for ld.lld
On Wed, Oct 20, 2021 at 09:31:32PM +, Alistair Delva wrote: > Cap end of relocations by the binary size. > > Linkers like to insert some auxiliary sections between .rela.dyn and > .bss_start. These sections don't make their way to the final binary, but > reloc_rela still tries to relocate them, resulting in attempted read > past the end of file. > > When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by > default on arm64) breaks the build. After this patch, U-Boot can be > linked successfully with and without CONFIG_STATIC_RELA. > > Originally-from: Elena Petrova > Signed-off-by: Alistair Delva > Cc: David Brazdil > Cc: Scott Wood > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] cmd: add acmconsole command
Hi Pali, Sorry for the late reply, On Mon, 27 Sept 2021 at 22:04, Pali Rohár wrote: > > On Thursday 19 August 2021 13:13:06 Loic Poulain wrote: > > This command allows to start CDC ACM function and redirect console > > (stdin, stdout, stderr) to USB (acmconsole start). The console can > > then be accessed through the USB host for debugging purpose. The > > host can stop the session (acmconsole stop) to revert back console > > to serial and unregister CDC ACM USB function. > > Hello! > > Could you rather implement this CDC ACM gadget in a way that calling > 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this > console redirect? Like it is supported for current usbtty or vga output > code. > > Then this acmconsole command would not be needed at all. Yes, that would be good, but AFAIR I restricted this cdc_acm usage to this command because we can't have fine grained control like e.g. using cdc_acm as stdout only, when used, it should necessarily be STDIN (at least). The reason is because of the single-tasking nature of u-boot, and the fact that we need to poll the USB controller for events via the 'usb_gadget_handle_interrupts()' function. In our case we simply do that in the getc() function, which is only called for input consoles in the u-boot mainloop. An alternative would be to have a u-boot API to register generic callbacks to be executed in the mainloop, but this is probably a different thread. Also we could possibly live with this 'bug' and simply accept that stdout-only configuration will be broken. Regards, Loic
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
On Tue, Nov 16, 2021 at 03:56:45PM +0100, Wolfgang Denk wrote: > Dear Tom, > > In message <2026141855.GD24579@bill-the-cat> you wrote: > > > > So, to quote lib/Kconfig: > > config NET_RANDOM_ETHADDR > > bool "Random ethaddr if unset" > > help > > Selecting this will allow the Ethernet interface to function > > even when the ethaddr variable for that interface is unset. > > A new MAC address will be generated on every boot and it will > > not be added to the environment. > > This description is at least incomplete, because it makes no > difference between the persistent copy of the environment and it's > in-memory copy. For network to function, I think the MAC address > must be stored in the in-memory copy of the environment. Well, networking has been working with NET_RANDOM_ETHADDR not updating the environment, with caveats that user display information that reads from the environment rather than ->enetaddr. In so far as the networking stack cares, ->enetaddr is what matters. We look at the environment for a MAC, and if it doesn't match the HW we use environment MAC, but warn. Now, I think RFC7042 is the current correct and relevant RFC here and it doesn't mention persistence. So I don't see a clear external authority on if locally administered MAC addresses like this should be persistent or not in this manner. > > We need either a re-spin or follow-up as we're changing the documented > > behavior. And as I mentioned in the other thread related on-going > > thread, perhaps "ethmacskip" should play a role in preserving existing > > behavior? > > We have way too many ways to do the same thing - nearly, just a > little different :-( Well, in this case I'm not sure that's the right problem to point at. We can just set ethmacskip as a bit of corner-case functionality and move on. Because honestly, the more I read this, the more I think https://patchwork.ozlabs.org/project/uboot/patch/2025121152.3470910-1-mich...@walle.cc/ is essentially the right direction. There's no reason for 'net list' to be using the environment here when ->enetaddr is what's being used by the stack. The use case of "I want to make my locally administered MAC persist because my USB ethernet adapter lacks a MAC address" is solved via the environment already. -- Tom signature.asc Description: PGP signature
[PATCH v5 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
- 1GiB DDR4 RAM
- 16 GiB eMMC
- SD card
- Gigabit ethernet
- USBOTG1 peripheral - fastboot
Signed-off-by: Ariel D'Alessandro
---
arch/arm/dts/Makefile | 1 +
.../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256
arch/arm/dts/imx8mn-var-som-symphony.dts | 240
arch/arm/dts/imx8mn-var-som.dtsi | 547 ++
arch/arm/mach-imx/imx8m/Kconfig | 9 +
board/variscite/imx8mn_var_som/Kconfig| 17 +
board/variscite/imx8mn_var_som/MAINTAINERS| 7 +
board/variscite/imx8mn_var_som/Makefile | 12 +
board/variscite/imx8mn_var_som/ddr4_timing.c | 528 +
.../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 +
.../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 +
board/variscite/imx8mn_var_som/spl.c | 93 +++
configs/imx8mn_var_som_defconfig | 98
doc/board/index.rst | 1 +
doc/board/variscite/imx8mn_var_som.rst| 56 ++
doc/board/variscite/index.rst | 9 +
include/configs/imx8mn_var_som.h | 90 +++
17 files changed, 2004 insertions(+)
create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
create mode 100644 board/variscite/imx8mn_var_som/Kconfig
create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
create mode 100644 board/variscite/imx8mn_var_som/Makefile
create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
create mode 100644 board/variscite/imx8mn_var_som/spl.c
create mode 100644 configs/imx8mn_var_som_defconfig
create mode 100644 doc/board/variscite/imx8mn_var_som.rst
create mode 100644 doc/board/variscite/index.rst
create mode 100644 include/configs/imx8mn_var_som.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd83..8d27876fa0e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -901,6 +901,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-ddr4-evk.dtb \
imx8mq-cm.dtb \
imx8mn-evk.dtb \
+ imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
new file mode 100644
index 000..ce475885df6
--- /dev/null
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Collabora Ltd.
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+};
+
+&{/soc@0} {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_24m {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_reg_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+_uart4 {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+_wdog {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot-spl-ddr {
+ align = <4>;
+ align-size = <4>;
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+
+ u-boot-spl {
+ align-end = <4>;
+ filename = "u-boot-spl.bin";
+ };
+
+ 1d-imem {
+ filename = "ddr4_imem_1d.bin";
+ size = <0x8000>;
+ type = "blob-ext";
+ };
+
+ 1d_dmem {
+ filename = "ddr4_dmem_1d.bin";
+ size = <0x4000>;
+ type = "blob-ext";
+ };
+
+ 2d_imem {
+ filename =
[PATCH v5 0/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Changes in v5: * Fixed documentation. Changes in v4: * Added board documentation. * Cleaned up board config. Changes in v3: * Picked device tree from kernel. * Properly added MAINTAINERS entry. * Removed CONFIG_SPL_BUILD anti-pattern in board config. Changes in v2: * Reordered dt properties alphabetically. * Removed downstream stuff in bootargs. * Fixed binman configuration. * Several code styling fixes. Ariel D'Alessandro (1): imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board arch/arm/dts/Makefile | 1 + .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256 arch/arm/dts/imx8mn-var-som-symphony.dts | 240 arch/arm/dts/imx8mn-var-som.dtsi | 547 ++ arch/arm/mach-imx/imx8m/Kconfig | 9 + board/variscite/imx8mn_var_som/Kconfig| 17 + board/variscite/imx8mn_var_som/MAINTAINERS| 7 + board/variscite/imx8mn_var_som/Makefile | 12 + board/variscite/imx8mn_var_som/ddr4_timing.c | 528 + .../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 + .../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 + board/variscite/imx8mn_var_som/spl.c | 93 +++ configs/imx8mn_var_som_defconfig | 98 doc/board/index.rst | 1 + doc/board/variscite/imx8mn_var_som.rst| 56 ++ doc/board/variscite/index.rst | 9 + include/configs/imx8mn_var_som.h | 90 +++ 17 files changed, 2004 insertions(+) create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi create mode 100644 board/variscite/imx8mn_var_som/Kconfig create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS create mode 100644 board/variscite/imx8mn_var_som/Makefile create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg create mode 100644 board/variscite/imx8mn_var_som/spl.c create mode 100644 configs/imx8mn_var_som_defconfig create mode 100644 doc/board/variscite/imx8mn_var_som.rst create mode 100644 doc/board/variscite/index.rst create mode 100644 include/configs/imx8mn_var_som.h -- 2.30.2
Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Hi Tom, On 11/16/21 2:52 PM, Tom Rini wrote: > On Tue, Nov 16, 2021 at 11:26:01AM -0300, Ariel D'Alessandro wrote: > >> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: >> >> - 1GiB DDR4 RAM >> - 16 GiB eMMC >> - SD card >> - Gigabit ethernet >> - USBOTG1 peripheral - fastboot >> >> Signed-off-by: Ariel D'Alessandro >> --- >> arch/arm/dts/Makefile | 1 + >> .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256 >> arch/arm/dts/imx8mn-var-som-symphony.dts | 240 >> arch/arm/dts/imx8mn-var-som.dtsi | 547 ++ >> arch/arm/mach-imx/imx8m/Kconfig | 9 + >> board/variscite/imx8mn_var_som/Kconfig| 17 + >> board/variscite/imx8mn_var_som/MAINTAINERS| 7 + >> board/variscite/imx8mn_var_som/Makefile | 12 + >> board/variscite/imx8mn_var_som/ddr4_timing.c | 528 + >> .../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 + >> .../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 + >> board/variscite/imx8mn_var_som/spl.c | 93 +++ >> configs/imx8mn_var_som_defconfig | 98 >> doc/board/variscite/imx8mn_var_som.rst| 56 ++ >> doc/board/variscite/index.rst | 9 + > > You need to update doc/board/index.rst as well, otherwise you get: > Warning, treated as error: > /home/trini/work/u-boot/u-boot/doc/board/variscite/index.rst:document isn't > included in any toctree > make[1]: *** [doc/Makefile:68: htmldocs] Error 2 > make: *** [Makefile:2250: htmldocs] Error 2 > > The easiest way to test doc building is: > $ virtualenv -p /usr/bin/python3 /tmp/venv > $ ( . /tmp/venv/bin/activate ; pip install -r doc/sphinx/requirements.txt ; > make htmldocs) Fixed, thanks a lot for the patience :-)
Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
On 11/16/21 2:54 PM, Fabio Estevam wrote: > On Tue, Nov 16, 2021 at 11:26 AM Ariel D'Alessandro > wrote: > >> --- /dev/null >> +++ b/doc/board/variscite/imx8mn_var_som.rst >> @@ -0,0 +1,56 @@ >> +.. SPDX-License-Identifier: GPL-2.0+ >> + >> +imx8mn_evk >> +== > > Copy and paste error :-) Ugh, :hard-facepalm: Thanks!
[PATCH 1/1] doc: fix typos in trace.rst
Fix obvious typos. Use US spelling consistently. Signed-off-by: Heinrich Schuchardt --- doc/develop/trace.rst | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst index 7776c48428..09f5745a90 100644 --- a/doc/develop/trace.rst +++ b/doc/develop/trace.rst @@ -4,7 +4,7 @@ Tracing in U-Boot = -U-Boot supports a simple tracing feature which allows a record of excecution +U-Boot supports a simple tracing feature which allows a record of execution to be collected and sent to a host machine for analysis. At present the main use for this is to profile boot time. @@ -161,10 +161,10 @@ limit of the trace buffer size you have specified. Once that is exhausted no more data will be collected. Collecting trace data has an affect on execution time/performance. You -will notice this particularly with trvial functions - the overhead of +will notice this particularly with trivial functions - the overhead of recording their execution may even exceed their normal execution time. In practice this doesn't matter much so long as you are aware of the -effect. Once you have done your optimisations, turn off tracing before +effect. Once you have done your optimizations, turn off tracing before doing end-to-end timing. The best time to start tracing is right at the beginning of U-Boot. The @@ -184,7 +184,7 @@ the OS. In practical terms, U-Boot runs the 'fakegocmd' environment variable at this point. This variable should have a short script which collects the trace data and writes it somewhere. -Trace data collection relies on a microsecond timer, accesed through +Trace data collection relies on a microsecond timer, accessed through timer_get_us(). So the first think you should do is make sure that this produces sensible results for your board. Suitable sources for this timer include high resolution timers, PWMs or profile timers if @@ -285,7 +285,7 @@ Options Specify U-Boot map file -p -Specifiy profile/trace file +Specify profile/trace file Commands: @@ -315,11 +315,11 @@ time: 2. Build U-Boot with tracing and run it. Note the difference in boot time (it is common for tracing to add 10% to the time) -3. Collect the trace information as descibed above. Use this to find where +3. Collect the trace information as described above. Use this to find where all the time is being spent. -4. Take a look at that code and see if you can optimise it. Perhaps it is - possible to speed up the initialisation of a device, or remove an unused +4. Take a look at that code and see if you can optimize it. Perhaps it is + possible to speed up the initialization of a device, or remove an unused feature. 5. Rebuild, run and collect again. Compare your results. -- 2.32.0
[PATCH 1/1] scripts: update spelling.txt from upstream Linux
This list is used by checkpatch.pl. The Linux v5.15 version has several words that where mispelled in U-Boot too. Signed-off-by: Heinrich Schuchardt --- scripts/spelling.txt | 365 ++- 1 file changed, 360 insertions(+), 5 deletions(-) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 9a058cff49..17fdc620d5 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -9,7 +9,12 @@ # abandonning||abandoning abigious||ambiguous +abitrary||arbitrary abitrate||arbitrate +abnornally||abnormally +abnrormal||abnormal +abord||abort +aboslute||absolute abov||above abreviated||abbreviated absense||absence @@ -17,6 +22,7 @@ absolut||absolute absoulte||absolute acccess||access acceess||access +accelaration||acceleration acceleratoin||acceleration accelleration||acceleration accesing||accessing @@ -25,6 +31,7 @@ accessable||accessible accesss||access accidentaly||accidentally accidentually||accidentally +acclerated||accelerated accoding||according accomodate||accommodate accomodates||accommodates @@ -34,8 +41,11 @@ accout||account accquire||acquire accquired||acquired accross||across +accumalate||accumulate +accumalator||accumulator acessable||accessible acess||access +acessing||accessing achitecture||architecture acient||ancient acitions||actions @@ -49,7 +59,9 @@ activete||activate actived||activated actualy||actually acumulating||accumulating +acumulative||accumulative acumulator||accumulator +acutally||actually adapater||adapter addional||additional additionaly||additionally @@ -58,18 +70,22 @@ addres||address adddress||address addreses||addresses addresss||address +addrress||address aditional||additional aditionally||additionally aditionaly||additionally adminstrative||administrative adress||address adresses||addresses +adrresses||addresses +advertisment||advertisement adviced||advised afecting||affecting againt||against agaist||against aggreataon||aggregation aggreation||aggregation +ajust||adjust albumns||albums alegorical||allegorical algined||aligned @@ -77,6 +93,7 @@ algorith||algorithm algorithmical||algorithmically algoritm||algorithm algoritms||algorithms +algorithmn||algorithm algorrithm||algorithm algorritm||algorithm aligment||alignment @@ -88,6 +105,7 @@ alloated||allocated allocatote||allocate allocatrd||allocated allocte||allocate +allocted||allocated allpication||application alocate||allocate alogirhtms||algorithms @@ -95,11 +113,16 @@ alogrithm||algorithm alot||a lot alow||allow alows||allows +alreay||already +alredy||already altough||although alue||value ambigious||ambiguous +ambigous||ambiguous amoung||among amout||amount +amplifer||amplifier +amplifyer||amplifier an union||a union an user||a user an userspace||a userspace @@ -130,6 +153,7 @@ arbitary||arbitrary architechture||architecture arguement||argument arguements||arguments +arithmatic||arithmetic aritmetic||arithmetic arne't||aren't arraival||arrival @@ -138,27 +162,42 @@ artillary||artillery asign||assign asser||assert assertation||assertion +assertting||asserting +assgined||assigned assiged||assigned assigment||assignment assigments||assignments assistent||assistant +assocaited||associated +assocating||associating assocation||association associcated||associated assotiated||associated +asssert||assert assum||assume assumtpion||assumption asuming||assuming asycronous||asynchronous asynchnous||asynchronous +asynchromous||asynchronous +asymetric||asymmetric +asymmeric||asymmetric +atleast||at least atomatically||automatically atomicly||atomically atempt||attempt +atrributes||attributes attachement||attachment +attatch||attach attched||attached +attemp||attempt attemps||attempts attemping||attempting +attepmpt||attempt +attnetion||attention attruibutes||attributes authentification||authentication +authenicated||authenticated automaticaly||automatically automaticly||automatically automatize||automate @@ -172,6 +211,7 @@ avaible||available availabe||available availabled||available availablity||availability +availaible||available availale||available availavility||availability availble||available @@ -205,28 +245,42 @@ boardcast||broadcast borad||board boundry||boundary brievely||briefly +brigde||bridge +broadcase||broadcast broadcat||broadcast +bufer||buffer +bufufer||buffer cacluated||calculated +caculate||calculate caculation||calculation +cadidate||candidate +cahces||caches calender||calendar calescing||coalescing calle||called callibration||calibration +callled||called +callser||caller calucate||calculate calulate||calculate cancelation||cancellation cancle||cancel +canot||cannot capabilites||capabilities +capabilties||capabilities capabilty||capability capabitilies||capabilities +capablity||capability capatibilities||capabilities capapbilities||capabilities +caputure||capture carefuly||carefully cariage||carriage catagory||category cehck||check
Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
On Tue, Nov 16, 2021 at 11:26 AM Ariel D'Alessandro wrote: > --- /dev/null > +++ b/doc/board/variscite/imx8mn_var_som.rst > @@ -0,0 +1,56 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +imx8mn_evk > +== Copy and paste error :-)
Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
On Tue, Nov 16, 2021 at 11:26:01AM -0300, Ariel D'Alessandro wrote: > Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: > > - 1GiB DDR4 RAM > - 16 GiB eMMC > - SD card > - Gigabit ethernet > - USBOTG1 peripheral - fastboot > > Signed-off-by: Ariel D'Alessandro > --- > arch/arm/dts/Makefile | 1 + > .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256 > arch/arm/dts/imx8mn-var-som-symphony.dts | 240 > arch/arm/dts/imx8mn-var-som.dtsi | 547 ++ > arch/arm/mach-imx/imx8m/Kconfig | 9 + > board/variscite/imx8mn_var_som/Kconfig| 17 + > board/variscite/imx8mn_var_som/MAINTAINERS| 7 + > board/variscite/imx8mn_var_som/Makefile | 12 + > board/variscite/imx8mn_var_som/ddr4_timing.c | 528 + > .../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 + > .../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 + > board/variscite/imx8mn_var_som/spl.c | 93 +++ > configs/imx8mn_var_som_defconfig | 98 > doc/board/variscite/imx8mn_var_som.rst| 56 ++ > doc/board/variscite/index.rst | 9 + You need to update doc/board/index.rst as well, otherwise you get: Warning, treated as error: /home/trini/work/u-boot/u-boot/doc/board/variscite/index.rst:document isn't included in any toctree make[1]: *** [doc/Makefile:68: htmldocs] Error 2 make: *** [Makefile:2250: htmldocs] Error 2 The easiest way to test doc building is: $ virtualenv -p /usr/bin/python3 /tmp/venv $ ( . /tmp/venv/bin/activate ; pip install -r doc/sphinx/requirements.txt ; make htmldocs) Thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model
Hello Gaurav,
> -Original Message-
> From: U-Boot On Behalf Of Gaurav Jain
> Sent: Monday, November 15, 2021 8:00 AM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ;
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean ; Gaurav Jain
>
> Subject: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver
> model
>
>
> added device tree support for job ring driver.
> sec is initialized based on job ring information processed
> from device tree.
>
> Signed-off-by: Gaurav Jain
> Reviewed-by: Ye Li
> ---
> cmd/Kconfig | 1 +
> drivers/crypto/fsl/Kconfig | 7 +
> drivers/crypto/fsl/Makefile | 4 +-
> drivers/crypto/fsl/jr.c | 316 +++-
> drivers/crypto/fsl/jr.h | 14 ++
> 5 files changed, 232 insertions(+), 110 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5b30b13e43..2b24672505 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2009,6 +2009,7 @@ config CMD_AES
>
> config CMD_BLOB
> bool "Enable the 'blob' command"
> + select FSL_BLOB
> depends on !MX6ULL && !MX6SLL && !MX6SL
> select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
> help
> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
> index 94ff540111..ab59d516f8 100644
> --- a/drivers/crypto/fsl/Kconfig
> +++ b/drivers/crypto/fsl/Kconfig
> @@ -66,4 +66,11 @@ config FSL_CAAM_RNG
> using the prediction resistance flag which means the DRGB is
> reseeded from the TRNG every time random data is generated.
>
> +config FSL_BLOB
> +bool "Enable Blob Encap/Decap, Blob KEK support"
> + help
> + Enable support for the hardware based crytographic blob encap/decap
> + module of the CAAM. blobs can be safely placed into non-volatile
> + storage. blobs can only be decapsulated by the SoC that created it.
> + Enable support for blob key encryption key generation.
> endif
> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> index f9c3ccecfc..738535b8e4 100644
> --- a/drivers/crypto/fsl/Makefile
> +++ b/drivers/crypto/fsl/Makefile
> @@ -1,10 +1,12 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
> # Copyright 2014 Freescale Semiconductor, Inc.
> +# Copyright 2021 NXP
>
> obj-y += sec.o
> obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
> +obj-$(CONFIG_FSL_BLOB) += fsl_blob.o
> +obj-$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
> obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
> obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
> obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 22b649219e..eea2225a1e 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright 2008-2014 Freescale Semiconductor, Inc.
> - * Copyright 2018 NXP
> + * Copyright 2018, 2021 NXP
> *
> * Based on CAAM driver in drivers/crypto/caam in Linux
> */
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include "fsl_sec.h"
> #include "jr.h"
> #include "jobdesc.h"
> #include "desc_constr.h"
> @@ -21,8 +20,11 @@
> #include
> #include
> #endif
> +#include
> #include
> #include
> +#include
> +#include
>
> #define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
> #define CIRC_SPACE(head, tail, size) CIRC_CNT((tail), (head) + 1, (size))
> @@ -35,20 +37,30 @@ uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
> #endif
> };
>
> +#if CONFIG_IS_ENABLED(DM)
> +struct udevice *caam_dev;
> +#else
> #define SEC_ADDR(idx) \
> (ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
>
> #define SEC_JR0_ADDR(idx) \
> (ulong)(SEC_ADDR(idx) + \
> (CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> +struct caam_regs caam_st;
> +#endif
>
> -struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
> +static inline u32 jr_start_reg(u8 jrid)
> +{
> + return (1 << jrid);
> +}
>
> -static inline void start_jr0(uint8_t sec_idx)
> +#ifndef CONFIG_ARCH_IMX8
> +static inline void start_jr(struct caam_regs *caam)
> {
> - ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> + ccsr_sec_t *sec = caam->sec;
> u32 ctpr_ms = sec_in32(>ctpr_ms);
> u32 scfgr = sec_in32(>scfgr);
> + u32 jrstart = jr_start_reg(caam->jrid);
>
> if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
> /* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or
> @@ -56,23 +68,17 @@ static inline void start_jr0(uint8_t sec_idx)
>
Re: [PATCH v4] lib: sparse: Make CHUNK_TYPE_RAW buffer aligned
On 11/15/21 8:35 PM, qianfangui...@qq.com wrote:
From: qianfan Zhao
CHUNK_TYPE_RAW buffer is not aligned, and flash sparse images by
fastboot will report "Misaligned operation" if DCACHE is enabled.
Flashing Sparse Image
CACHE: Misaligned operation at range [8428, 84001028]
CACHE: Misaligned operation at range [84001034, 84002034]
CACHE: Misaligned operation at range [8401104c, 8401304c]
Fix it
Signed-off-by: qianfan Zhao
---
lib/image-sparse.c | 69 --
1 file changed, 61 insertions(+), 8 deletions(-)
diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index d80fdbbf58..5ec0f94ab3 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -46,9 +46,66 @@
#include
#include
+#include
static void default_log(const char *ignored, char *response) {}
+static lbaint_t write_sparse_chunk_raw(struct sparse_storage *info,
+ lbaint_t blk, lbaint_t blkcnt,
+ void *data,
+ char *response)
+{
+ lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
+ uint32_t *aligned_buf = NULL;
+
+ if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
+ write_blks = info->write(info, blk, n, data);
+ if (write_blks < n)
+ goto write_fail;
+
+ return write_blks;
+ }
+
+ aligned_buf = memalign(ARCH_DMA_MINALIGN, info->blksz *
aligned_buf_blks);
+ if (!aligned_buf) {
+ info->mssg("Malloc failed for: CHUNK_TYPE_RAW", response);
+ return -ENOMEM;
+ }
+
+ while (blkcnt > 0) {
+ n = min(aligned_buf_blks, blkcnt);
+ memcpy(aligned_buf, data, n * info->blksz);
+
+ /* write_blks might be > n due to NAND bad-blocks */
nit: <
+ write_blks = info->write(info, blk + blks, n, aligned_buf);
+ if (write_blks < n) {
+ free(aligned_buf);
+ goto write_fail;
+ }
+
+ blks += write_blks;
+ data += n * info->blksz;
+ blkcnt -= n;
+ }
+
+ free(aligned_buf);
+ return blks;
+
+write_fail:
I think this label can be lower, but it does not affect correctness.
+ if (IS_ERR_VALUE(write_blks)) {
+ printf("%s: Write failed, block #" LBAFU " [" LBAFU "]
(%lld)\n",
+ __func__, blk + blks, n, (long long)write_blks);
+ info->mssg("flash write failure", response);
+ return write_blks;
+ }
+
+ /* write_blks < n */
+ printf("%s: Write failed, block #" LBAFU " [" LBAFU "]\n",
+ __func__, blk + blks, n);
+ info->mssg("flash write failure(incomplete)", response);
+ return -1;
-EIO?
+}
+
int write_sparse_image(struct sparse_storage *info,
const char *part_name, void *data, char *response)
{
@@ -152,15 +209,11 @@ int write_sparse_image(struct sparse_storage *info,
return -1;
}
- blks = info->write(info, blk, blkcnt, data);
- /* blks might be > blkcnt (eg. NAND bad-blocks) */
- if (blks < blkcnt) {
- printf("%s: %s" LBAFU " [" LBAFU "]\n",
- __func__, "Write failed, block #",
- blk, blks);
- info->mssg("flash write failure", response);
+ blks = write_sparse_chunk_raw(info, blk, blkcnt,
+ data, response);
+ if (blks < 0)
return -1;
ditto
- }
+
blk += blks;
bytes_written += ((u64)blkcnt) * info->blksz;
total_blocks += chunk_header->chunk_sz;
Reviewed-by: Sean Anderson
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
Dear Tom, In message <2026141855.GD24579@bill-the-cat> you wrote: > > So, to quote lib/Kconfig: > config NET_RANDOM_ETHADDR > bool "Random ethaddr if unset" > help > Selecting this will allow the Ethernet interface to function > even when the ethaddr variable for that interface is unset. > A new MAC address will be generated on every boot and it will > not be added to the environment. This description is at least incomplete, because it makes no difference between the persistent copy of the environment and it's in-memory copy. For network to function, I think the MAC address must be stored in the in-memory copy of the environment. > We need either a re-spin or follow-up as we're changing the documented > behavior. And as I mentioned in the other thread related on-going > thread, perhaps "ethmacskip" should play a role in preserving existing > behavior? We have way too many ways to do the same thing - nearly, just a little different :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A little knowledge is a dangerous thing."- Doug Gwyn
Re: [PATCH RFC] cmd: fix net list command
Dear Tom, In message <2026141030.GC24579@bill-the-cat> you wrote: > > One thing I'm not totally sure on yet is, looking at the README I see: > "If Ethernet drivers implement the 'write_hwaddr' function, valid MAC > addresses will be programmed into hardware as part of the initialization > process. This may be skipped by setting the appropriate 'ethmacskip' > environment variable. The naming convention is as follows: "ethmacskip" > (=>eth0), "eth1macskip" (=>eth1) etc." I have to admit that until now I was not even aware of these variables... > As I'm sure that predates device trees being used to the extent they are > now, should 'ethmacskip' be involved in the "fixup the device tree" > logic, and appropriate rST / Kconfig help text updated? My first > reaction is that in spirit, this is how to solve Michael's use case and > README / doc/README.enetaddr do not specify when/why the "also fixup the > device tree if it exists" is done. Apparently this logic was added more than 10 years ago in commit ecee9324d "Program net device MAC addresses after initializing". I think it does not change anything to the logic that Linux uses the MAC address passed by U-Boot. Whether U-Boot also writes some MAC address to the device's persistent storage is an independent act. If there already was an addressed stored there befoire it would not have been read by Linux, so the same should happen here. [Here it is even less problematic as U-Boot has the very same MAC address in it's environment.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_
[GIT PULL] xilinx patches for v2022.01-rc3
Hi Tom, Please pull these changes to your tree. CI loop doesn't show any issue with these patches. Thanks, Michal The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d: Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2022.01-rc3 for you to fetch changes up to 11c0255cd8a7177e2b714040efcfd51844cb5d8e: xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check (2021-11-15 15:59:33 +0100) Xilinx changes for v2022.01-rc3 sdhci: - Fix emmc mini case with missing firmware interface zynqmp: - Restore JTAG interface if required - Allow overriding board name - Add support for DLC21 - Fix one fallthrought statement description - Use config macro instead of name duplication - Save multiboot to variable firmware: - Handle ipi_req errors better - Use local buffer in case user doesn't need it instead of NULL/0 location spi: - gqsi: Fix write issue at low frequencies net: - gem: Disable broadcasts Ashok Reddy Soma (1): spi: zynqmp_gqspi: Fix write issue at low frequencies Jorge Ramirez-Ortiz (1): zynqmp: restore the jtag interface Liam Beguin (1): arm64: zynqmp: allow overriding board name Michal Simek (9): arm64: zynqmp: Add support for DLC21 (Smartlynq+) board arm64: zynqmp: Fix sgmii clock input freq for p-a2197 net: gem: Disable broadcast setting firmware: zynqmp: Handle errors from ipi_req properly firmware: zynqmp: fix write to an uninitialised pointer in ipi_req() xilinx: zynqmp: Handle fallthrough statement properly xilinx: zynqmp: Use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME xilinx: zynqmp: Save multiboot as variable arm64: zynqmp: Replace comma by semicolon Ricardo Salveti (1): xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check T Karthik Reddy (1): mmc: zynq_sdhci: Add xilinx_pm_request weak function arch/arm/dts/Makefile| 1 + arch/arm/dts/zynqmp-dlc21-revA.dts | 221 ++ arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 2 +- arch/arm/mach-zynqmp/Kconfig | 9 + arch/arm/mach-zynqmp/include/mach/hardware.h | 31 +++- board/xilinx/zynqmp/zynqmp-dlc21-revA/psu_init_gpl.c | 922 +++ board/xilinx/zynqmp/zynqmp.c | 48 - configs/xilinx_zynqmp_virt_defconfig | 2 +- drivers/firmware/firmware-zynqmp.c | 10 +- drivers/mmc/zynq_sdhci.c | 6 + drivers/net/zynq_gem.c | 2 + drivers/spi/zynqmp_gqspi.c | 11 +- 12 files changed, 1243 insertions(+), 22 deletions(-) create mode 100644 arch/arm/dts/zynqmp-dlc21-revA.dts create mode 100644 board/xilinx/zynqmp/zynqmp-dlc21-revA/psu_init_gpl.c
[PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
- 1GiB DDR4 RAM
- 16 GiB eMMC
- SD card
- Gigabit ethernet
- USBOTG1 peripheral - fastboot
Signed-off-by: Ariel D'Alessandro
---
arch/arm/dts/Makefile | 1 +
.../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256
arch/arm/dts/imx8mn-var-som-symphony.dts | 240
arch/arm/dts/imx8mn-var-som.dtsi | 547 ++
arch/arm/mach-imx/imx8m/Kconfig | 9 +
board/variscite/imx8mn_var_som/Kconfig| 17 +
board/variscite/imx8mn_var_som/MAINTAINERS| 7 +
board/variscite/imx8mn_var_som/Makefile | 12 +
board/variscite/imx8mn_var_som/ddr4_timing.c | 528 +
.../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 +
.../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 +
board/variscite/imx8mn_var_som/spl.c | 93 +++
configs/imx8mn_var_som_defconfig | 98
doc/board/variscite/imx8mn_var_som.rst| 56 ++
doc/board/variscite/index.rst | 9 +
include/configs/imx8mn_var_som.h | 90 +++
16 files changed, 2003 insertions(+)
create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
create mode 100644 board/variscite/imx8mn_var_som/Kconfig
create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
create mode 100644 board/variscite/imx8mn_var_som/Makefile
create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
create mode 100644 board/variscite/imx8mn_var_som/spl.c
create mode 100644 configs/imx8mn_var_som_defconfig
create mode 100644 doc/board/variscite/imx8mn_var_som.rst
create mode 100644 doc/board/variscite/index.rst
create mode 100644 include/configs/imx8mn_var_som.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd83..8d27876fa0e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -901,6 +901,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-ddr4-evk.dtb \
imx8mq-cm.dtb \
imx8mn-evk.dtb \
+ imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
new file mode 100644
index 000..ce475885df6
--- /dev/null
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Collabora Ltd.
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+};
+
+&{/soc@0} {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_24m {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_reg_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+_uart4 {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+_wdog {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot-spl-ddr {
+ align = <4>;
+ align-size = <4>;
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+
+ u-boot-spl {
+ align-end = <4>;
+ filename = "u-boot-spl.bin";
+ };
+
+ 1d-imem {
+ filename = "ddr4_imem_1d.bin";
+ size = <0x8000>;
+ type = "blob-ext";
+ };
+
+ 1d_dmem {
+ filename = "ddr4_dmem_1d.bin";
+ size = <0x4000>;
+ type = "blob-ext";
+ };
+
+ 2d_imem {
+ filename = "ddr4_imem_2d.bin";
+ size =
[PATCH v4 0/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Changes in v4: * Added board documentation. * Cleaned up board config. Changes in v3: * Picked device tree from kernel. * Properly added MAINTAINERS entry. * Removed CONFIG_SPL_BUILD anti-pattern in board config. Changes in v2: * Reordered dt properties alphabetically. * Removed downstream stuff in bootargs. * Fixed binman configuration. * Several code styling fixes. Ariel D'Alessandro (1): imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board arch/arm/dts/Makefile | 1 + .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256 arch/arm/dts/imx8mn-var-som-symphony.dts | 240 arch/arm/dts/imx8mn-var-som.dtsi | 547 ++ arch/arm/mach-imx/imx8m/Kconfig | 9 + board/variscite/imx8mn_var_som/Kconfig| 17 + board/variscite/imx8mn_var_som/MAINTAINERS| 7 + board/variscite/imx8mn_var_som/Makefile | 12 + board/variscite/imx8mn_var_som/ddr4_timing.c | 528 + .../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 + .../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 + board/variscite/imx8mn_var_som/spl.c | 93 +++ configs/imx8mn_var_som_defconfig | 98 doc/board/variscite/imx8mn_var_som.rst| 56 ++ doc/board/variscite/index.rst | 9 + include/configs/imx8mn_var_som.h | 90 +++ 16 files changed, 2003 insertions(+) create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi create mode 100644 board/variscite/imx8mn_var_som/Kconfig create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS create mode 100644 board/variscite/imx8mn_var_som/Makefile create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg create mode 100644 board/variscite/imx8mn_var_som/spl.c create mode 100644 configs/imx8mn_var_som_defconfig create mode 100644 doc/board/variscite/imx8mn_var_som.rst create mode 100644 doc/board/variscite/index.rst create mode 100644 include/configs/imx8mn_var_som.h -- 2.30.2
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
On Thu, Nov 11, 2021 at 10:10:57AM +0100, Michael Walle wrote: > Hi Ramon, > > Am 2021-11-09 14:55, schrieb Michael Walle: > > Am 2021-11-04 22:00, schrieb Ramon Fried: > > > > > What's the verdict ? We're keeping this patch ? > > > > There was a good point from Grygorii: linux might deal > > in its own way with missing ethernet addresses (and warn > > the user about it because its usually an error). > > > > And IMHO that net list can be fixed in a different way. > > > > If this patch is accepted, it should be clearly documented > > in the Kconfig help text. And as I said, it changes behavior. > > So this patch now in your pull request. Why are you even asking > then? So, to quote lib/Kconfig: config NET_RANDOM_ETHADDR bool "Random ethaddr if unset" help Selecting this will allow the Ethernet interface to function even when the ethaddr variable for that interface is unset. A new MAC address will be generated on every boot and it will not be added to the environment. We need either a re-spin or follow-up as we're changing the documented behavior. And as I mentioned in the other thread related on-going thread, perhaps "ethmacskip" should play a role in preserving existing behavior? -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC] cmd: fix net list command
On Tue, Nov 16, 2021 at 02:33:01PM +0100, Wolfgang Denk wrote: > Dear Ramon, > > In message > you > wrote: > > > > It appears that Michael has some board and a scenario that *this* bug > > was working for his best interest, where he can have two distinct MAC > > addresses, one in U-boot and one in Linux. > > If the Linux environment is supposed to be a specific MAC address > (which may be different from the one passed by U-Boot), then there > are standard tools available to set the address. I don't see a > problem here. One thing I'm not totally sure on yet is, looking at the README I see: "If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses will be programmed into hardware as part of the initialization process. This may be skipped by setting the appropriate 'ethmacskip' environment variable. The naming convention is as follows: "ethmacskip" (=>eth0), "eth1macskip" (=>eth1) etc." As I'm sure that predates device trees being used to the extent they are now, should 'ethmacskip' be involved in the "fixup the device tree" logic, and appropriate rST / Kconfig help text updated? My first reaction is that in spirit, this is how to solve Michael's use case and README / doc/README.enetaddr do not specify when/why the "also fixup the device tree if it exists" is done. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Hi Fabio, On 11/16/21 8:37 AM, Fabio Estevam wrote: > Hi Ariel, > > The patch looks good. Only some minor comments: > > On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro > wrote: >> >> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: >> >> - 1GiB DDR4 RAM >> - 16 GiB eMMC >> - SD card >> - Gigabit ethernet >> - USBOTG1 peripheral - fastboot >> >> Signed-off-by: Ariel D'Alessandro > > It would be nice to have a README file so that the users can know how > to build and flash mainline > U-Boot in this board. Added that to doc/board/variscite/imx8mn_var_som.rst Will submit in v4. > >> +#define PHYS_SDRAM 0x4000 >> +#define PHYS_SDRAM_SIZESZ_1G /* 1GB DDR */ >> + >> +#define CONFIG_BAUDRATE115200 > > This is the default. No need to be specified here. Ack. > >> +#define CONFIG_MXC_UART_BASE UART4_BASE_ADDR >> + >> +/* Monitor Command Prompt */ >> +#define CONFIG_SYS_CBSIZE SZ_2K >> +#define CONFIG_SYS_MAXARGS 64 >> +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE >> +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ >> +sizeof(CONFIG_SYS_PROMPT) + 16) >> + >> +/* USDHC */ >> +#define CONFIG_FSL_USDHC > > This should be placed in defconfig. Done. > >> +#define CONFIG_SYS_FSL_USDHC_NUM 2 > > This is not used. Please remove it. Done. Thanks a lot, Ariel
Re: [PATCH v7 02/12] tools: build mkeficapsule with tools-only_defconfig
On 11/16/21 13:20, Heinrich Schuchardt wrote: On 11/16/21 05:32, AKASHI Takahiro wrote: We want to always build mkeficapsule if tools-only_defconfig is used. Signed-off-by: AKASHI Takahiro Reviewed-by: Heinrich Schuchardt --- configs/tools-only_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig index f482c9a1c1b0..5427797dd4c3 100644 --- a/configs/tools-only_defconfig +++ b/configs/tools-only_defconfig @@ -31,3 +31,4 @@ CONFIG_I2C_EDID=y # CONFIG_VIRTIO_MMIO is not set # CONFIG_VIRTIO_PCI is not set # CONFIG_VIRTIO_SANDBOX is not set +CONFIG_TOOLS_MKEFICAPSULE=y You cannot use a symbol that is not yet defined. Please, swap patches 2 and 3 when resubmitting. Best regards Heinrich
Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Hi Tom, On 11/16/21 10:13 AM, Tom Rini wrote: > On Tue, Nov 16, 2021 at 08:37:06AM -0300, Fabio Estevam wrote: >> Hi Ariel, >> >> The patch looks good. Only some minor comments: >> >> On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro >> wrote: >>> >>> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: >>> >>> - 1GiB DDR4 RAM >>> - 16 GiB eMMC >>> - SD card >>> - Gigabit ethernet >>> - USBOTG1 peripheral - fastboot >>> >>> Signed-off-by: Ariel D'Alessandro >> >> It would be nice to have a README file so that the users can know how >> to build and flash mainline >> U-Boot in this board. > > And that means an entry under doc/board/variscite/ to be clear. Yes :-) thanks, will add it in v4.
Re: [PATCH 1/1] pxe: simplify label_boot()
On Tue, Nov 16, 2021 at 03:09:58PM +0800, Art Nikpal wrote:
> On Tue, Nov 16, 2021 at 2:26 AM Heinrich Schuchardt
> wrote:
> >
> > Coverity CID 131256 indicates a possible buffer overflow in label_boot().
> > This would only occur if the size of the downloaded file would exceed 4
> > GiB. But anyway we can simplify the code by using snprintf() and checking
> > the return value.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > boot/pxe_utils.c | 9 -
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> > index a7a84f26c1..5841561bdf 100644
> > --- a/boot/pxe_utils.c
> > +++ b/boot/pxe_utils.c
> > @@ -465,11 +465,10 @@ static int label_boot(struct pxe_context *ctx, struct
> > pxe_label *label)
> > }
> >
> > initrd_addr_str = env_get("ramdisk_addr_r");
> > - strcpy(initrd_filesize, simple_xtoa(size));
> > -
> > - strncpy(initrd_str, initrd_addr_str, 18);
> > - strcat(initrd_str, ":");
> > - strncat(initrd_str, initrd_filesize, 9);
> > + size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
> > + initrd_addr_str, size);
> > + if (size >= sizeof(initrd_str))
> > + return 1;
> > }
> >
> > if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
>
> Reviewed-by: Artem Lapkin
Thanks for the review everyone and thanks for the patch Heinrich. It
looks like in the kernel the new'ish standard tag is:
Addresses-Coverity-ID: 131256 ("Security best practices violations")
and then not need to mention Coverity in the main message. I'll fix
things up slightly when applying.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH RFC] cmd: fix net list command
Dear Ramon, In message you wrote: > > It appears that Michael has some board and a scenario that *this* bug > was working for his best interest, where he can have two distinct MAC > addresses, one in U-boot and one in Linux. If the Linux environment is supposed to be a specific MAC address (which may be different from the one passed by U-Boot), then there are standard tools available to set the address. I don't see a problem here. > Mark and I already provided work around for Michael to delete the > environment variable before he boots. or implement the necessary OTP > driver in U-Boot. As Marek pointed out, in this specific case it would be best to provide such a driver. > From my end, I think we can conclude the discussion. ACK. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de My challenge to the goto-less programmer is to recode tcp_input() without any gotos ... without any loss of efficiency (there has to be a catch). - W. R. Stevens
Re: [PATCH RFC] cmd: fix net list command
Dear Michal, In message you wrote: > > In perfect world u-boot will just get it and use. And if manufacturer > doesn't do it properly but want to enable ethernet in u-boot random > address could be a solution for them. > And then in Linux where drivers are available you will use the right one. You miss the point. The whole argument is about who is control of the system - can I as user do what I want, or are there some stupid limitations in the system that prevent me from doing it. But if the user of the system decides to use a specific MAC address (for whatever reason ever), the software should just do what he requests, and use this MAC address on no other one. It is up to the user to decide which is "the right one". > But back to this patch. I think it is good that net list will show all > mac addresses even they are not saved in environment. Agreed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A girl with a future avoids the man with a past. -- Evan Esar, "The Humor of Humor"
Re: [PATCH RFC] cmd: fix net list command
Dear Tom, In message <2025154516.GR24579@bill-the-cat> you wrote: > > > One practical use case is board provisioning in the factory, which > > includes setting up valid produt data like serial number, MAC > > address etc. Yes, this can be done over serial consone as well, but > > 1) this is slower than network and 2) many commecial products don't > > have the connector etc. populated. > > Is that the case for the layerscape or imx8 families? I know on the TI > side these values are derived from chip-specific fuses that are blown at > chip production so we don't need an initial random one. I'd have to > pull up some NXP manuals to see what's the case there, but I think some > other people on the thread know the answers here already. This is actually independent of the hardware, I think. It is more or less a management decision how board bringup / inital commissioning is organized. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In a business, marketroids, salespukes, and lawyers have different goals from those who actually do work and produce something. Usually, is is the former who triumph over the latter, due to the simple rule that those who print the money make the rules. -- Tom Christiansen in <5jdcls$b04$2...@csnews.cs.colorado.edu>
Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
On Tue, Nov 16, 2021 at 08:37:06AM -0300, Fabio Estevam wrote: > Hi Ariel, > > The patch looks good. Only some minor comments: > > On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro > wrote: > > > > Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for: > > > > - 1GiB DDR4 RAM > > - 16 GiB eMMC > > - SD card > > - Gigabit ethernet > > - USBOTG1 peripheral - fastboot > > > > Signed-off-by: Ariel D'Alessandro > > It would be nice to have a README file so that the users can know how > to build and flash mainline > U-Boot in this board. And that means an entry under doc/board/variscite/ to be clear. -- Tom signature.asc Description: PGP signature
[PATCH 18/18] km/ls102xa: use unused scratchrw4 address for post word
The SCRATCHRW4 is only used in secure boot scenario that is unsupported by
our design, so this address can be stolen for storing POST status.
The SCRATCHRW4 is initialized to zero at core rest.
Using a DDR address was unfortunate choice, the DDR at boot time has a
random contend and it happens that sometimes is matching POST magic number.
This behavior can lead to undefined POST behavior and u-boot ending in
failbootcmd command.
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index a37d111..467f110 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -162,19 +162,18 @@ int post_hotkeys_pressed(void)
return qrio_get_selftest_pin();
}
+/* POST word is located in the unused SCRATCHRW4 register */
+#define CCSR_SCRATCHRW4_ADDR 0x1ee020c
+
ulong post_word_load(void)
{
- /* POST word is located at the beginning of reserved physical RAM */
- void *addr = (void *)(CONFIG_SYS_SDRAM_BASE +
- gd->ram_size - CONFIG_KM_RESERVED_PRAM + 8);
+ void *addr = (void *)CCSR_SCRATCHRW4_ADDR;
return in_le32(addr);
}
void post_word_store(ulong value)
{
- /* POST word is located at the beginning of reserved physical RAM */
- void *addr = (void *)(CONFIG_SYS_SDRAM_BASE +
- gd->ram_size - CONFIG_KM_RESERVED_PRAM + 8);
+ void *addr = (void *)CCSR_SCRATCHRW4_ADDR;
out_le32(addr, value);
}
--
1.8.3.1
[PATCH 17/18] configs/expu1/seli8: limit autoboot stop to space key
Make it in a same way as on the other FOXMC products, this also helps to avoid unwanted stop caused by some terminal servers that are sending junk on the serial line. Signed-off-by: Aleksandar Gerasimovski --- configs/pg_wcom_expu1_defconfig | 3 +++ configs/pg_wcom_seli8_defconfig | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig index 0ff96e5..65ac373 100644 --- a/configs/pg_wcom_expu1_defconfig +++ b/configs/pg_wcom_expu1_defconfig @@ -28,6 +28,9 @@ CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=3 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_STOP_STR=" " +CONFIG_AUTOBOOT_PROMPT="Hit key to stop autoboot in %2ds\n" CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0" CONFIG_SILENT_CONSOLE=y diff --git a/configs/pg_wcom_seli8_defconfig b/configs/pg_wcom_seli8_defconfig index f13cc55..9124c31 100644 --- a/configs/pg_wcom_seli8_defconfig +++ b/configs/pg_wcom_seli8_defconfig @@ -28,6 +28,9 @@ CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=3 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_STOP_STR=" " +CONFIG_AUTOBOOT_PROMPT="Hit key to stop autoboot in %2ds\n" CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0" CONFIG_SILENT_CONSOLE=y -- 1.8.3.1
[PATCH 16/18] arm/expu1/seli8: adapt dts NOR partition table to the latest used
Even not used by u-boot, this has to be inline with the hw and kernel dts.
U-boot partition table is defined by MTDPARTS_DEFAULT Kconfig.
Signed-off-by: Aleksandar Gerasimovski
---
arch/arm/dts/ls1021a-pg-wcom-expu1.dts | 15 +--
arch/arm/dts/ls1021a-pg-wcom-seli8.dts | 14 +-
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
b/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
index 33456b7..ec8e7de 100644
--- a/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
+++ b/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
@@ -87,7 +87,6 @@
label = "qe";
reg = <0x2 0x2>;
};
- /* ZL30343 init data to be added here */
partition@4 {
label = "envred";
reg = <0x4 0x2>;
@@ -101,8 +100,20 @@
reg = <0x10 0x10>;
};
partition@20 {
+ label = "redenvred";
+ reg = <0x20 0x2>;
+ };
+ partition@22 {
+ label = "redenv";
+ reg = <0x22 0x2>;
+ };
+ partition@24 {
+ label = "redu-boot";
+ reg = <0x24 0x10>;
+ };
+ partition@34 {
label = "ubi0";
- reg = <0x20 0x3E0>;
+ reg = <0x34 0x03C0>;
};
};
};
diff --git a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
index f2cadd7..03ce3ab 100644
--- a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
+++ b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
@@ -83,8 +83,20 @@
reg = <0x10 0x10>;
};
partition@20 {
+ label = "redenvred";
+ reg = <0x20 0x2>;
+ };
+ partition@22 {
+ label = "redenv";
+ reg = <0x22 0x2>;
+ };
+ partition@24 {
+ label = "redu-boot";
+ reg = <0x24 0x10>;
+ };
+ partition@34 {
label = "ubi0";
- reg = <0x20 0x3E0>;
+ reg = <0x34 0x03C0>;
};
};
};
--
1.8.3.1
[PATCH 15/18] configs/expu1: add u-boot update defconfig
This patch adds default defconfig for u-boot update version, the u-boot update defconfig is a copy of the default (factory) defconfig with: - adapted text base and environment addresses - explicit flag that this is a field updated u-boot version At the time of implementation this version is only used to verify the update procedure, in future depend on the needs this defconfig can be extended with additional options. Signed-off-by: Aleksandar Gerasimovski --- board/keymile/pg-wcom-ls102xa/MAINTAINERS | 1 + configs/pg_wcom_expu1_update_defconfig| 83 +++ 2 files changed, 84 insertions(+) create mode 100644 configs/pg_wcom_expu1_update_defconfig diff --git a/board/keymile/pg-wcom-ls102xa/MAINTAINERS b/board/keymile/pg-wcom-ls102xa/MAINTAINERS index 9fabad1..33db2b2 100644 --- a/board/keymile/pg-wcom-ls102xa/MAINTAINERS +++ b/board/keymile/pg-wcom-ls102xa/MAINTAINERS @@ -9,5 +9,6 @@ F: include/configs/pg-wcom-expu1.h F: configs/pg_wcom_seli8_defconfig F: configs/pg_wcom_seli8_update_defconfig F: configs/pg_wcom_expu1_defconfig +F: configs/pg_wcom_expu1_update_defconfig F: arch/arm/dts/ls1021a-pg-wcom-seli8.dts F: arch/arm/dts/ls1021a-pg-wcom-expu1.dts diff --git a/configs/pg_wcom_expu1_update_defconfig b/configs/pg_wcom_expu1_update_defconfig new file mode 100644 index 000..0fd5ebc --- /dev/null +++ b/configs/pg_wcom_expu1_update_defconfig @@ -0,0 +1,83 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_TARGET_PG_WCOM_EXPU1=y +CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y +CONFIG_PG_WCOM_UBOOT_UPDATE=y +CONFIG_SYS_TEXT_BASE=0x6024 +CONFIG_SYS_MALLOC_LEN=0x1004000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_KM_DEF_NETDEV="eth2" +CONFIG_KM_COMMON_ETH_INIT=y +CONFIG_PIGGY_MAC_ADDRESS_OFFSET=3 +CONFIG_SYS_MEMTEST_START=0x8000 +CONFIG_SYS_MEMTEST_END=0x9fff +CONFIG_ENV_SIZE=0x4000 +CONFIG_ENV_SECT_SIZE=0x2 +CONFIG_SYS_I2C_MXC_I2C1=y +CONFIG_SYS_I2C_MXC_I2C2=y +CONFIG_SYS_I2C_MXC_I2C3=y +CONFIG_DEFAULT_DEVICE_TREE="ls1021a-pg-wcom-expu1" +CONFIG_BOOTCOUNT_BOOTLIMIT=3 +CONFIG_SYS_BOOTCOUNT_ADDR=0x7020 +CONFIG_AHCI=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_SYS_LOAD_ADDR=0x8200 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_BOOTDELAY=3 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_STOP_STR=" " +CONFIG_AUTOBOOT_PROMPT="Hit key to stop autoboot in %2ds\n" +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0" +CONFIG_SILENT_CONSOLE=y +CONFIG_LAST_STAGE_INIT=y +CONFIG_MISC_INIT_R=y +CONFIG_CMD_IMLS=y +CONFIG_CMD_GREPENV=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y +CONFIG_CMD_NAND=y +CONFIG_CMD_NAND_TRIMFFS=y +CONFIG_CMD_CRAMFS=y +CONFIG_CMD_MTDPARTS=y +CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash" +CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)" +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_IN_FLASH=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y +CONFIG_ENV_ADDR=0x6022 +CONFIG_ENV_ADDR_REDUND=0x6020 +CONFIG_DM=y +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_DDR_CLK_FREQ=5000 +CONFIG_SYS_FSL_DDR3=y +CONFIG_SYS_I2C_LEGACY=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_FLASH_CFI_MTD=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_FSL_IFC=y +CONFIG_SYS_NAND_ONFI_DETECTION=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_FIXED=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y +CONFIG_PHY_GIGE=y +CONFIG_MII=y +CONFIG_TSEC_ENET=y +CONFIG_SYS_QE_FW_ADDR=0x6002 +CONFIG_SPECIFY_CONSOLE_INDEX=y +CONFIG_DM_SERIAL=y +CONFIG_SYS_NS16550=y +CONFIG_VERSION_VARIABLE=y -- 1.8.3.1
[PATCH 14/18] configs/expu1: enable field fail-safe u-boot update
Field fail-safe u-boot update for pg-wcom-ls102x designs is introduced with 81fb05e. This patch enables already added support by: - Defining default u-boot build as bootpackage (factory) image. - Defining u-boot update image location according to the EXPU1 NOR layout. - Extending mtd partitions according defined EXPU1 NOR layout. Signed-off-by: Aleksandar Gerasimovski --- configs/pg_wcom_expu1_defconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig index 9e8697d..0ff96e5 100644 --- a/configs/pg_wcom_expu1_defconfig +++ b/configs/pg_wcom_expu1_defconfig @@ -1,7 +1,10 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_TARGET_PG_WCOM_EXPU1=y +CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y +CONFIG_PG_WCOM_UBOOT_BOOTPACKAGE=y CONFIG_SYS_TEXT_BASE=0x6010 +CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE=0x6024 CONFIG_SYS_MALLOC_LEN=0x1004000 CONFIG_NR_DRAM_BANKS=1 CONFIG_KM_DEF_NETDEV="eth2" @@ -41,7 +44,7 @@ CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_CRAMFS=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash" -CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),-(ubi0);6800.flash:-(ubi1)" +CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)" CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y -- 1.8.3.1
[PATCH 13/18] configs: expu1: enable ver envvar for version_string
This is used by out ESW for reading u-boot build version. Signed-off-by: Aleksandar Gerasimovski --- configs/pg_wcom_expu1_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig index 267864f..9e8697d 100644 --- a/configs/pg_wcom_expu1_defconfig +++ b/configs/pg_wcom_expu1_defconfig @@ -75,3 +75,4 @@ CONFIG_SYS_QE_FW_ADDR=0x6002 CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_VERSION_VARIABLE=y -- 1.8.3.1
[PATCH 12/18] configs: seli8: enable ver envvar for version_string
This is used by out ESW for reading u-boot build version. Signed-off-by: Aleksandar Gerasimovski --- configs/pg_wcom_seli8_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/pg_wcom_seli8_defconfig b/configs/pg_wcom_seli8_defconfig index cb7c680..f13cc55 100644 --- a/configs/pg_wcom_seli8_defconfig +++ b/configs/pg_wcom_seli8_defconfig @@ -78,3 +78,4 @@ CONFIG_SYS_QE_FW_ADDR=0x6002 CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_VERSION_VARIABLE=y -- 1.8.3.1
[PATCH 11/18] km/ls102xa: fix device disable configuration
This was probably broken when mainlining, CONFIG_FSL_DEVICE_DISABLE is
not Kconfig but whitelisted.
It's fine to be without flag as this is always enabled for abec1020
(pg-wcom-ls102xa.h)
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index 3dae423..a37d111 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -137,8 +137,7 @@ int board_late_init(void)
int misc_init_r(void)
{
- if (IS_ENABLED(CONFIG_FSL_DEVICE_DISABLE))
- device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
+ device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
ivm_read_eeprom(ivm_content, CONFIG_SYS_IVM_EEPROM_MAX_LEN,
CONFIG_PIGGY_MAC_ADDRESS_OFFSET);
--
1.8.3.1
[PATCH 10/18] configs/seli8: add u-boot update defconfig
This patch adds default defconfig for u-boot update version, the u-boot update defconfig is a copy of the default (factory) defconfig with: - adapted text base and environment addresses - explicit flag that this is a field updated u-boot version At the time of implementation this version is only used to verify the update procedure, in future depend on the needs this defconfig can be extended with additional options. Signed-off-by: Aleksandar Gerasimovski --- board/keymile/pg-wcom-ls102xa/MAINTAINERS | 1 + configs/pg_wcom_seli8_update_defconfig| 83 +++ 2 files changed, 84 insertions(+) create mode 100644 configs/pg_wcom_seli8_update_defconfig diff --git a/board/keymile/pg-wcom-ls102xa/MAINTAINERS b/board/keymile/pg-wcom-ls102xa/MAINTAINERS index 966c88b..9fabad1 100644 --- a/board/keymile/pg-wcom-ls102xa/MAINTAINERS +++ b/board/keymile/pg-wcom-ls102xa/MAINTAINERS @@ -7,6 +7,7 @@ F: include/configs/km/pg-wcom-ls102xa.h F: include/configs/pg-wcom-seli8.h F: include/configs/pg-wcom-expu1.h F: configs/pg_wcom_seli8_defconfig +F: configs/pg_wcom_seli8_update_defconfig F: configs/pg_wcom_expu1_defconfig F: arch/arm/dts/ls1021a-pg-wcom-seli8.dts F: arch/arm/dts/ls1021a-pg-wcom-expu1.dts diff --git a/configs/pg_wcom_seli8_update_defconfig b/configs/pg_wcom_seli8_update_defconfig new file mode 100644 index 000..fb5b715 --- /dev/null +++ b/configs/pg_wcom_seli8_update_defconfig @@ -0,0 +1,83 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_TARGET_PG_WCOM_SELI8=y +CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y +CONFIG_PG_WCOM_UBOOT_UPDATE=y +CONFIG_SYS_TEXT_BASE=0x6024 +CONFIG_SYS_MALLOC_LEN=0x1004000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_KM_DEF_NETDEV="eth2" +CONFIG_KM_COMMON_ETH_INIT=y +CONFIG_PIGGY_MAC_ADDRESS_OFFSET=3 +CONFIG_SYS_MEMTEST_START=0x8000 +CONFIG_SYS_MEMTEST_END=0x9fff +CONFIG_ENV_SIZE=0x4000 +CONFIG_ENV_SECT_SIZE=0x2 +CONFIG_SYS_I2C_MXC_I2C1=y +CONFIG_SYS_I2C_MXC_I2C2=y +CONFIG_SYS_I2C_MXC_I2C3=y +CONFIG_DEFAULT_DEVICE_TREE="ls1021a-pg-wcom-seli8" +CONFIG_BOOTCOUNT_BOOTLIMIT=3 +CONFIG_SYS_BOOTCOUNT_ADDR=0x7020 +CONFIG_AHCI=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_SYS_LOAD_ADDR=0x8200 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_BOOTDELAY=3 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_STOP_STR=" " +CONFIG_AUTOBOOT_PROMPT="Hit key to stop autoboot in %2ds\n" +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0" +CONFIG_SILENT_CONSOLE=y +CONFIG_LAST_STAGE_INIT=y +CONFIG_MISC_INIT_R=y +CONFIG_CMD_IMLS=y +CONFIG_CMD_GREPENV=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y +CONFIG_CMD_NAND=y +CONFIG_CMD_NAND_TRIMFFS=y +CONFIG_CMD_CRAMFS=y +CONFIG_CMD_MTDPARTS=y +CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash" +CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)" +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_IN_FLASH=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y +CONFIG_ENV_ADDR=0x6022 +CONFIG_ENV_ADDR_REDUND=0x6020 +CONFIG_DM=y +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_DDR_CLK_FREQ=5000 +CONFIG_SYS_FSL_DDR3=y +CONFIG_SYS_I2C_LEGACY=y +# CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_FLASH_CFI_MTD=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_FSL_IFC=y +CONFIG_SYS_NAND_ONFI_DETECTION=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_FIXED=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y +CONFIG_PHY_GIGE=y +CONFIG_MII=y +CONFIG_TSEC_ENET=y +CONFIG_SYS_QE_FW_ADDR=0x6002 +CONFIG_SPECIFY_CONSOLE_INDEX=y +CONFIG_DM_SERIAL=y +CONFIG_SYS_NS16550=y +CONFIG_VERSION_VARIABLE=y -- 1.8.3.1
Re: [PATCH v2] pci: Work around PCIe link training failures
Hello! On Tuesday 16 November 2021 11:35:24 Maciej W. Rozycki wrote: > Attempt to handle cases with a downstream port of a PCIe switch where > link training never completes and the link continues switching between > speeds indefinitely with the data link layer never reaching the active > state. > > It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 > switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 > switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, > P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the > switches are supposed to negotiate the link speed of preferably 5.0GT/s, > falling back to 2.5GT/s. > > However the link continues oscillating between the two speeds, at the > rate of 34-35 times per second, with link training reported active ~84% > of the time repeatedly, e.g.: > > 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet > Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode]) > [...] > Bus: primary=02, secondary=05, subordinate=05, sec-latency=0 > [...] > Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00 > [...] > LnkSta: Speed 5GT/s (downgraded), Width x1 (ok) > TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt- > [...] > LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, > Selectable De-emphasis: -3.5dB >Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- >Compliance De-emphasis: -6dB > [...] > > Forcibly limiting the target link speed to 2.5GT/s with the upstream > ASM2824 device makes the two switches communicate correctly however: > > 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet > Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode]) > [...] > Bus: primary=02, secondary=05, subordinate=09, sec-latency=0 > [...] > Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00 > [...] > LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) > TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- > [...] > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- > SpeedDis+, Selectable De-emphasis: -3.5dB >Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- >Compliance De-emphasis: -6dB > [...] > > and then: > > 05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 > 3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode]) > [...] > Bus: primary=05, secondary=06, subordinate=09, sec-latency=0 > [...] > Capabilities: [c0] Express (v2) Upstream Port, MSI 00 > [...] > LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) > TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > [...] > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- >Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- >Compliance De-emphasis: -6dB > [...] > > Make use of this observation then and attempt to detect the inability to > negotiate the link speed automatically, and then handle it by hand. Use > the Data Link Layer Link Active status flag as the primary indicator of > successful link speed negotiation, but given that the flag is optional > by hardware to implement (the ASM2824 does have it though), resort to > checking for the mandatory Link Bandwidth Management Status flag showing > that the link speed or width has been changed in an attempt to correct > unreliable link operation (the ASM2824 does set it too). > > If these checks indicate that link may not operate correctly, then poll > the Data Link Layer Link Active status flag along with the Link Training > flag for the duration of 200ms to see if the link has stabilised, that > is either that the Data Link Layer Link Active status flag has been set > or that Link Training has been inactive during at least the second half > of the inteval. > > If that has indicated failure, reduce the target speed, request a link > retrain and check again if the link has stabilised. Repeat until either > successful or the link speeds supported by the downstream port have been > exhausted. I would like to hear what Bjorn Helgaas thinks about this issue at all and how to handle it, without potentially break something else. And based on the fact that in U-Boot's PCI core code there is no such global quirk implemented, I really do not know if U-Boot maintainers and developers want to review and understand all PCI Express aspect of this code and possible side-effects. This is just what I think about it, I do not have maintainer hat. I suggested to to first send this fixup to the Linux kernel for proper review (or to
[PATCH 08/18] km/ls102xa: add support for field fail-safe u-boot
Field fail-safe u-boot update procedure for pg-wcom boards is defined and
implemented by 59b3403.
This patch invokes the update procedure for pg-wcom-ls102x designs during
early misc_init_f execution.
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 7 +++
include/configs/km/pg-wcom-ls102xa.h| 2 ++
2 files changed, 9 insertions(+)
diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index cff18dc..3dae423 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -109,6 +109,13 @@ int board_early_init_f(void)
return 0;
}
+int misc_init_f(void)
+{
+ if (IS_ENABLED(CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED))
+ check_for_uboot_update();
+ return 0;
+}
+
int board_init(void)
{
if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_A010315))
diff --git a/include/configs/km/pg-wcom-ls102xa.h
b/include/configs/km/pg-wcom-ls102xa.h
index 743d09e..249bcef 100644
--- a/include/configs/km/pg-wcom-ls102xa.h
+++ b/include/configs/km/pg-wcom-ls102xa.h
@@ -280,4 +280,6 @@
#define CONFIG_SYS_BOOTM_LEN (64 << 20) /* Increase max gunzip size */
#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* Increase map for Linux */
+#define CONFIG_MISC_INIT_F
+
#endif
--
1.8.3.1
[PATCH 07/18] km: common: implement field fail-safe u-boot update
This patch provides possibility for field fail-safe u-boot updates.
The implementation can be used on all pg-wcom boards that are booting from
parallel NOR flash.
When used in a board design, provided check_for_uboot_update function will
start new u-boot at defined location if updateduboot envvar is set to yes.
With this implementation it is expected that factory programmed u-boot
will always stay as it is, and optionally new u-boot can be safely
programmed by embedded software when the unit is rolled out on the field.
It is expected check_for_uboot_update to be called early in execution
before relocation (*_f) once SoC is basically initialized and environment
can be read, with this possibilities to not be able to fix a u-boot bug by
a u-boot update are reduced to minimum.
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/Kconfig | 32 ++
board/keymile/common/common.c | 53 +++
board/keymile/common/common.h | 1 +
3 files changed, 86 insertions(+)
diff --git a/board/keymile/Kconfig b/board/keymile/Kconfig
index 7dd8213..863c07d 100644
--- a/board/keymile/Kconfig
+++ b/board/keymile/Kconfig
@@ -130,6 +130,38 @@ config SYS_IVM_EEPROM_PAGE_LEN
help
Page size of inventory in EEPROM.
+config PG_WCOM_UBOOT_UPDATE_SUPPORTED
+ bool "Enable U-boot Field Fail-Safe Update Functionality"
+ default n
+ help
+ Indicates that field fail-safe u-boot update is supported.
+ This functionality works only for designs that are booting
+ from parallel NOR flash.
+
+config PG_WCOM_UBOOT_BOOTPACKAGE
+ bool "U-boot Is Part Of Factory Boot-Package Image"
+ default n
+ help
+ Indicates that u-boot will be a part of the factory programmed
+ boot-package image.
+ Has to be set for original u-boot programmed at factory.
+
+config PG_WCOM_UBOOT_UPDATE_TEXT_BASE
+ hex "Text Base For U-boot Programmed Outside Factory"
+ default 0x
+ help
+ Text base of an updated u-boot that is not factory programmed but
+ later when the unit is rolled out on the field.
+ Has to be set for original u-boot programmed at factory.
+
+config PG_WCOM_UBOOT_UPDATE
+ bool "U-boot Is Part Of Factory Boot-Package Image"
+ default n
+ help
+ Indicates that u-boot will be a part of the embedded software and
+ programmed at field.
+ Has to be set for updated u-boot version programmed at field.
+
source "board/keymile/km83xx/Kconfig"
source "board/keymile/kmcent2/Kconfig"
source "board/keymile/km_arm/Kconfig"
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index ff07260..3999f48 100644
--- a/board/keymile/common/common.c
+++ b/board/keymile/common/common.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#if defined(CONFIG_POST)
#include "post.h"
@@ -76,6 +78,57 @@ int set_km_env(void)
return 0;
}
+#if CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE_SUPPORTED)
+#if ((!CONFIG_IS_ENABLED(PG_WCOM_UBOOT_BOOTPACKAGE) && \
+ !CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE)) || \
+ (CONFIG_IS_ENABLED(PG_WCOM_UBOOT_BOOTPACKAGE) && \
+ CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE)))
+#error "It has to be either bootpackage or update u-boot image!"
+#endif
+void check_for_uboot_update(void)
+{
+ void (*uboot_update_entry)(void) =
+ (void (*)(void)) CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE;
+ char *isupdated = env_get("updateduboot");
+ ulong bootcount = bootcount_load();
+ ulong ebootcount = 0;
+
+ if (IS_ENABLED(CONFIG_PG_WCOM_UBOOT_BOOTPACKAGE)) {
+ /*
+* When running in factory burned u-boot move to the updated
+* u-boot version only if updateduboot envvar is set to 'yes'
+* and bootcount limit is not exceeded.
+* Board must be able to start in factory bootloader mode!
+*/
+ if (isupdated && !strncmp(isupdated, "yes", 3) &&
+ bootcount <= CONFIG_BOOTCOUNT_BOOTLIMIT) {
+ printf("Check update: update detected, ");
+ printf("starting new image @%08x ...\n",
+ CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE);
+ ebootcount = early_bootcount_load();
+ if (ebootcount <= CONFIG_BOOTCOUNT_BOOTLIMIT) {
+ early_bootcount_store(++ebootcount);
+ uboot_update_entry();
+ } else {
+ printf("Check update: warning: ");
+ printf("early bootcount exceeded (%lu)\n",
+ ebootcount);
+ }
+ }
+ printf("Check update: starting factory image @%08x ...\n",
+
Re: Your message to U-Boot awaits moderator approval
On Tue, Nov 16, 2021 at 10:26:37AM +, Sahil Malhotra (OSS) wrote: > Hi, > > I am trying to send some patches on u-boot@lists.denx.de but every time I am > getting reply "Your message to U-Boot awaits moderator approval". > Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the > list u-boot@lists.denx.de. > > Tried multiple times, but always getting this reply. > Any help regarding this is really appreciated. Yes, your messages and then subscription (I'm not sure whey, on the latter) were waiting for approval, which is now done. -- Tom signature.asc Description: PGP signature
RE: [EXT] Your message to U-Boot awaits moderator approval
Hi, I am trying to send some patches on u-boot@lists.denx.de but every time I am getting reply "Your message to U-Boot awaits moderator approval". Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the list u-boot@lists.denx.de. Tried multiple times, but always getting this reply. Any help regarding this is really appreciated. Regards, Sahil Malhotra -Original Message- From: U-Boot On Behalf Of u-boot-ow...@lists.denx.de Sent: Tuesday, November 16, 2021 2:05 PM To: Sahil Malhotra Subject: [EXT] Your message to U-Boot awaits moderator approval Caution: EXT Email Your mail to 'U-Boot' with the subject [PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fconfirm%2Fu-boot%2Fc921389ccb7759ac41403909f360475b5243a75ddata=04%7C01%7Csahil.malhotra%40nxp.com%7C64ce15466de943b4c9cf08d9a8dc06ea%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637726485232188800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qBbVbxrlgCIP4Y7yNQDxYixWJPzQnmJvyXACZakrQmE%3Dreserved=0
RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS
> -Original Message-
> From: Ramon Fried
> Sent: 2021年11月16日 18:45
> To: Joakim Zhang
> Cc: Joe Hershberger ; U-Boot Mailing List
> ; Ye Li ; Patrick Delaunay
> ; Daniil Stas ;
> Stephen Warren
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
>
> On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang
> wrote:
> >
> >
> > Hi Ramon,
> >
> > > -Original Message-
> > > From: Ramon Fried
> > > Sent: 2021年11月16日 13:57
> > > To: Joakim Zhang
> > > Cc: Joe Hershberger ; U-Boot Mailing List
> > > ; Ye Li ; Patrick Delaunay
> > > ; Daniil Stas
> > > ; Stephen Warren
> > > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe
> > > stage instead of starting EQOS
> > >
> > > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> > >
> > > wrote:
> > > >
> > > > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > > > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > > > auto negotiation to complete when do tftp boot.
> > > > phy_config()
> > > > -> board_phy_config()
> > > > -> phydev->drv->config() // i.MX8MP/DXL use
> > > realtek PHY
> > > > -> rtl8211f_config()
> > > > -> genphy_config_aneg()
> > > > ->
> > > genphy_restart_aneg()
> > > > // restart auto-nego, then need seconds to complete
> > > >
> > > > To avoid wasting time, we can move PHY connection and
> > > > configuration from
> > > > eqos_start() to eqos_probe(). This patch also moves clock setting
> > > > from
> > > > eqos_start() to eqos_probe() as MDIO access need CSR clock, there
> > > > is no function change.
> > > >
> > > > Tested-on: i.MX8MP & i.MX8DXL
> > > >
> > > > Before:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > > > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > > > (313 ms) Using ethernet@30bf device TFTP from server
> > > > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > > > gateway 10.193.102.254
> > > > After:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > > > address is 10.193.102.192; sending through gateway 10.193.102.254
> > > >
> > > How much time do you save exactly, Is it the ~140ms you show here at
> > > the commit log ?
> >
> > Exactly not. This time points to DHCP client bound to address, not the time
> this patch saves.
> >
> > How can we evaluate the time we save? Please see the log:
> >
> > Before:
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> done
> > BOOTP broadcast 1
> > After:
> > Booting from net ...
> > BOOTP broadcast 1
> >
> > And you need to check the related code:
> > drivers/net/dwc_eth_qos.c: phy_startup ->...->
> > drivers/net/phy/phy.c: genphy_update_link()
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> %2Fphy
> > %2Fphy.c%23L225data=04%7C01%7Cqiangqing.zhang%40nxp.com%
> 7C59322db
> >
> 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7
> >
> C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=usRIR7L
> exBnk
> > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3Dreserved=0
> >
> > while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> > /*
> > * Timeout reached ?
> > */
> > if (i > (PHY_ANEG_TIMEOUT / 50)) {
> > printf(" TIMEOUT !\n");
> > phydev->link = 0;
> > return -ETIMEDOUT;
> > }
> >
> > if (ctrlc()) {
> > puts("user interrupt!\n");
> > phydev->link = 0;
> > return -EINTR;
> > }
> >
> > if ((i++ % 10) == 0)
> > printf(".");
> >
> > mii_reg = phy_read(phydev,
> MDIO_DEVAD_NONE, MII_BMSR);
> > mdelay(50); /* 50 ms */
> > }
> >
> > We can see that one "." is about 500ms, so from the log, we save about
> 500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete
> auto-nego.
> >
> > I also described this in the commit message, "users need wait seconds for
> PHY auto negotiation to complete when do tftp boot", may not quite clear, I
> will improve it.
> >
> > Best Regards,
> >
RE: Your message to U-Boot awaits moderator approval
Hi, I am trying to send some patches on u-boot@lists.denx.de but every time I am getting reply "Your message to U-Boot awaits moderator approval". Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the list u-boot@lists.denx.de. Tried multiple times, but always getting this reply. Any help regarding this is really appreciated. Regards, Sahil Malhotra -Original Message- From: U-Boot On Behalf Of u-boot-ow...@lists.denx.de Sent: Tuesday, November 16, 2021 3:47 PM To: Sahil Malhotra (OSS) Subject: Your message to U-Boot awaits moderator approval Your mail to 'U-Boot' with the subject [PATCH 1/2] fsl-layerscape: add dtb overlay feature Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://lists.denx.de/confirm/u-boot/1d3c54aafb0ee9f189c3cef4f19bfd29f25cf5ed
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
From: Sahil Malhotra SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
board_init.c file not compiled
Hello all, I'm new to u-boot and having difficulty while trying to build u-boot for our test board.(arm64, armv8) I wanted to try the "SPL falcon" mode". The DDR is not ready yet in the board. A small scp chip(cortex-M7) will initialize clk and will load kernel(including initramfs), dtb, u-boot-spl, images to a small internal RAM. And the AP chip will start from the u-boot-spl. (I know some low-level init can be skipped) I added SPL related config settings and ran this command. make CROSS_COMPILE=aarch64-none-elf- ab21m_defconfig make CROSS_COMPILE=aarch64-none-elf- I see "u-boot/arch/arm/lib/crt0_64.S:88: undefined reference to `board_init_f_alloc_reserve'" error during the u-boot build. (not related to SPL). By comparing the build process with that of rk3036 board (arm board with SUPPORT_SPL, no SUPPORT_TPL), I found in my case even common/board_init.c is not compiled. Where should I look? I'm reading the documents or build scripts here and there but can't figure it out. Thank you. Chan Kim
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
From: Sahil Malhotra SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS
Hi Ramon,
> -Original Message-
> From: Ramon Fried
> Sent: 2021年11月16日 13:57
> To: Joakim Zhang
> Cc: Joe Hershberger ; U-Boot Mailing List
> ; Ye Li ; Patrick Delaunay
> ; Daniil Stas ;
> Stephen Warren
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
>
> On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> wrote:
> >
> > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > auto negotiation to complete when do tftp boot.
> > phy_config()
> > -> board_phy_config()
> > -> phydev->drv->config() // i.MX8MP/DXL use
> realtek PHY
> > -> rtl8211f_config()
> > -> genphy_config_aneg()
> > ->
> genphy_restart_aneg()
> > // restart auto-nego, then need seconds to complete
> >
> > To avoid wasting time, we can move PHY connection and configuration
> > from
> > eqos_start() to eqos_probe(). This patch also moves clock setting from
> > eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
> > no function change.
> >
> > Tested-on: i.MX8MP & i.MX8DXL
> >
> > Before:
> > u-boot=> run netboot
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > (313 ms) Using ethernet@30bf device TFTP from server
> > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > gateway 10.193.102.254
> > After:
> > u-boot=> run netboot
> > Booting from net ...
> > BOOTP broadcast 1
> > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > address is 10.193.102.192; sending through gateway 10.193.102.254
> >
> How much time do you save exactly, Is it the ~140ms you show here at the
> commit log ?
Exactly not. This time points to DHCP client bound to address, not the time
this patch saves.
How can we evaluate the time we save? Please see the log:
Before:
Booting from net ...
ethernet@30bf Waiting for PHY auto negotiation to complete... done
BOOTP broadcast 1
After:
Booting from net ...
BOOTP broadcast 1
And you need to check the related code:
drivers/net/dwc_eth_qos.c: phy_startup ->...->
drivers/net/phy/phy.c: genphy_update_link()
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/phy/phy.c#L225
while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
/*
* Timeout reached ?
*/
if (i > (PHY_ANEG_TIMEOUT / 50)) {
printf(" TIMEOUT !\n");
phydev->link = 0;
return -ETIMEDOUT;
}
if (ctrlc()) {
puts("user interrupt!\n");
phydev->link = 0;
return -EINTR;
}
if ((i++ % 10) == 0)
printf(".");
mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);
mdelay(50); /* 50 ms */
}
We can see that one "." is about 500ms, so from the log, we save about
500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete
auto-nego.
I also described this in the commit message, "users need wait seconds for PHY
auto negotiation to complete when do tftp boot", may not quite clear, I will
improve it.
Best Regards,
Joakim Zhang
RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS
Hi Patrick,
> -Original Message-
> From: Patrick DELAUNAY
> Sent: 2021年11月15日 18:42
> To: Joakim Zhang ; joe.hershber...@ni.com;
> rfried@gmail.com
> Cc: u-boot@lists.denx.de; Ye Li ; daniil.s...@posteo.net;
> swar...@nvidia.com; Christophe ROULLIER
> ; Marek Vasut
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
>
> Hi,
>
> On 11/10/21 6:42 AM, Joakim Zhang wrote:
> > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > auto negotiation
>
> s/eqos_srart()/eqos_start()/
>
>
> > to complete when do tftp boot.
> > phy_config()
> > -> board_phy_config()
> > -> phydev->drv->config() // i.MX8MP/DXL use
> realtek PHY
> > -> rtl8211f_config()
> > -> genphy_config_aneg()
> > ->
> genphy_restart_aneg()
> > // restart auto-nego, then need seconds to complete
> >
> > To avoid wasting time, we can move PHY connection and configuration
> > from
> > eqos_start() to eqos_probe(). This patch also moves clock setting from
> > eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
> > no function change.
> >
> > Tested-on: i.MX8MP & i.MX8DXL
> >
> > Before:
> > u-boot=> run netboot
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > (313 ms) Using ethernet@30bf device TFTP from server
> > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > gateway 10.193.102.254
> > After:
> > u-boot=> run netboot
> > Booting from net ...
> > BOOTP broadcast 1
> > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > address is 10.193.102.192; sending through gateway 10.193.102.254
> >
> > Signed-off-by: Joakim Zhang
> > ---
> > drivers/net/dwc_eth_qos.c | 132
> +++---
> > 1 file changed, 67 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> > index 585101804d..c1923fbe6b 100644
> > --- a/drivers/net/dwc_eth_qos.c
> > +++ b/drivers/net/dwc_eth_qos.c
> > @@ -1045,20 +1045,6 @@ static int eqos_start(struct udevice *dev)
> > eqos->tx_desc_idx = 0;
> > eqos->rx_desc_idx = 0;
> >
> > - ret = eqos->config->ops->eqos_start_clks(dev);
> > - if (ret < 0) {
> > - pr_err("eqos_start_clks() failed: %d", ret);
> > - goto err;
> > - }
> > -
> > - ret = eqos->config->ops->eqos_start_resets(dev);
> > - if (ret < 0) {
> > - pr_err("eqos_start_resets() failed: %d", ret);
> > - goto err_stop_clks;
> > - }
> > -
> > - udelay(10);
> > -
> > eqos->reg_access_ok = true;
>
> => as clock is moved in probe...
>
> the line
> eqos->reg_access_ok = true
> should be also moved I think
>
> or reg_access_ok can be removed, as reg_access_ok is always one when
> eqos_write_hwaddr is called
Why? I saw this variable "reg_access_ok " doesn't have initialize value. If
remove this line,
I think it will break the logic in eqos_write_hwaddr(), so I agree also move it
into probe().
> >
> > ret = wait_for_bit_le32(>dma_regs->mode,
> > @@ -1066,68 +1052,34 @@ static int eqos_start(struct udevice *dev)
> > eqos->config->swr_wait, false);
> > if (ret) {
> > pr_err("EQOS_DMA_MODE_SWR stuck");
> > - goto err_stop_resets;
> > + goto err;
> > }
> >
> > ret = eqos->config->ops->eqos_calibrate_pads(dev);
> > if (ret < 0) {
> > pr_err("eqos_calibrate_pads() failed: %d", ret);
> > - goto err_stop_resets;
> > + goto err;
> > }
> > rate = eqos->config->ops->eqos_get_tick_clk_rate(dev);
> >
> > val = (rate / 100) - 1;
> > writel(val, >mac_regs->us_tic_counter);
> >
> > - /*
> > -* if PHY was already connected and configured,
> > -* don't need to reconnect/reconfigure again
> > -*/
> > - if (!eqos->phy) {
> > - int addr = -1;
> > -#ifdef CONFIG_DM_ETH_PHY
> > - addr = eth_phy_get_addr(dev);
> > -#endif
> > -#ifdef DWC_NET_PHYADDR
> > - addr = DWC_NET_PHYADDR;
> > -#endif
> > - eqos->phy = phy_connect(eqos->mii, addr, dev,
> > - eqos->config->interface(dev));
> > - if (!eqos->phy) {
> > - pr_err("phy_connect() failed");
> > - goto err_stop_resets;
> > - }
> > -
> > - if (eqos->max_speed) {
> > - ret = phy_set_supported(eqos->phy, eqos->max_speed);
> > - if (ret) {
> > - pr_err("phy_set_supported() failed: %d", ret);
> > -
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
From: Sahil Malhotra SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs
From: Sahil Malhotra SoCs enabled for DTB Overlay features are: LS1046A-RDB LS1043A-RDB LS1012A-RDB LS1028A-RDB LS1088A-RDB LS2088A-RDB Signed-off-by: Sahil Malhotra --- configs/ls1012ardb_tfa_defconfig | 2 ++ configs/ls1028ardb_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 2 ++ configs/ls1046ardb_tfa_defconfig | 2 ++ configs/ls1088ardb_tfa_defconfig | 2 ++ configs/ls2088ardb_tfa_defconfig | 2 ++ 6 files changed, 11 insertions(+) diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..49ee762e38 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,5 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..b360427eb3 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..a64df243f9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..55b6016e74 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..2351749d7d 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..d1b6e7f7ae 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,5 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_OF_SYSTEM_SETUP=y -- 2.17.1
[PATCH 1/2] fsl-layerscape: add dtb overlay feature
From: Sahil Malhotra
This patch enables the DTB overlay feature for LS platforms.
Signed-off-by: Sahil Malhotra
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c | 39 +++
arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h | 10 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 ++
.../cpu/armv8/fsl-layerscape/lowlevel_init.S | 25
5 files changed, 87 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
obj-y += soc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
endif
obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include
+#include
+#include
+#include
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+ int ret = 0;
+
+ /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+ if (!rom_pointer[0]) {
+ debug("No BL32_BASE passed means no TEE running\n");
+ return ret;
+ }
+
+ if (rom_pointer[2]) {
+ debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+ ret = fdt_check_header((void *)rom_pointer[2]);
+ if (ret == 0) {
+ /* Copy the fdt overlay to next 1M and use copied
overlay */
+ memcpy((void *)(rom_pointer[2] + SZ_1M), (void
*)rom_pointer[2],
+ fdt_totalsize((void *)rom_pointer[2]));
+ ret = fdt_overlay_apply_verbose(fdt, (void
*)(rom_pointer[2] + SZ_1M));
+ if (ret == 0) {
+ debug("Overlay applied with success");
+ fdt_pack(fdt);
+ }
+ }
+ }
+ return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
#endif
#include
#include
+#include "dt_optee.h"
int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
{
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
#endif
}
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+ return ft_add_optee_overlay(blob, bd);
+#else
+ return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include
+
+.align 8
+.global rom_pointer
+rom_pointer:
+ .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+ /* The firmware provided FDT address can be found in r2/x0 */
+ adr x0, rom_pointer
+ stp x1, x2, [x0], #16
+ stp x3, x4, [x0], #16
+
+ ldr x1, =save_boot_params_ret
+ br x1
--
2.17.1
[PATCH 06/18] km: qrio: add access functions for ebootcount
The EBOOTCNT is a reserved persistent static memory area in QRIO,
and similar to BOOTCNT is intended to be used as boot counter location.
Comparable to BOOTCNT that is reserved for u-boot main bootcount
infrastructure, EBOOTCNT is intended to be used for pg-wcom board
specific purposes (e.g implementing early boot counter for fail-safe
u-boot update).
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/common/common.h | 3 +++
board/keymile/common/qrio.c | 38 ++
2 files changed, 41 insertions(+)
diff --git a/board/keymile/common/common.h b/board/keymile/common/common.h
index 15a3c37..fc14728 100644
--- a/board/keymile/common/common.h
+++ b/board/keymile/common/common.h
@@ -133,6 +133,9 @@ int get_testpin(void);
int set_km_env(void);
+ulong early_bootcount_load(void);
+void early_bootcount_store(ulong ebootcount);
+
#define DELAY_ABORT_SEQ62 /* @200kHz 9 clocks = 44us, 62us is
ok */
#define DELAY_HALF_PERIOD (500 / (CONFIG_SYS_I2C_SPEED / 1000))
diff --git a/board/keymile/common/qrio.c b/board/keymile/common/qrio.c
index 89a9726..5401bdd 100644
--- a/board/keymile/common/qrio.c
+++ b/board/keymile/common/qrio.c
@@ -270,6 +270,44 @@ void qrio_uprstreq(u8 mode)
out_8(qrio_base + RSTCFG_OFF, rstcfg);
}
+/* Early bootcount memory area is avilable starting from QRIO3 Rev.2 */
+#define QRIO3_ID 0x71
+#define QRIO3_REV 0x02
+#define EBOOTCNT_OFF 0x28
+
+ulong early_bootcount_load(void)
+{
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+ u16 id_rev = in_be16(qrio_base + ID_REV_OFF);
+ u8 id = (id_rev >> 8) & 0xff;
+ u8 rev = id_rev & 0xff;
+ u32 ebootcount = 0;
+
+ if (id == QRIO3_ID && rev >= QRIO3_REV) {
+ ebootcount = in_be32(qrio_base + EBOOTCNT_OFF);
+ } else {
+ printf("QRIO: warning: early bootcount not supported, ");
+ printf("id = %u, rev = %u\n", id, rev);
+ }
+
+ return ebootcount;
+}
+
+void early_bootcount_store(ulong ebootcount)
+{
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+ u16 id_rev = in_be16(qrio_base + ID_REV_OFF);
+ u8 id = (id_rev >> 8) & 0xff;
+ u8 rev = id_rev & 0xff;
+
+ if (id == QRIO3_ID && rev >= QRIO3_REV) {
+ out_be32(qrio_base + EBOOTCNT_OFF, ebootcount);
+ } else {
+ printf("QRIO: warning: early bootcount not supported, ");
+ printf("id = %u, rev = %u\n", id, rev);
+ }
+}
+
/* I2C deblocking uses the algorithm defined in board/keymile/common/common.c
* 2 dedicated QRIO GPIOs externally pull the SCL and SDA lines
* For I2C only the low state is activly driven and high state is pulled-up
--
1.8.3.1
[PATCH 05/18] km/ls102xa: dbg phy prst depends on piggy presence
The PHY for the debug interface was placed on the board for the pg_wcom_ls102x. Hence only when a piggy is plugged, a RJ45 jack including magnetics is connected to the MDI of the PHY. Without a piggy the MDI lines are left floating and it does not make sense to have an active debug PHY. In case of expu1 an active PHY without a piggy even led to increased jitter for syncE. This patch only deactivates the prst line of the debug PHY when a piggy is detected persent. Signed-off-by: Rainer Boschung Signed-off-by: Aleksandar Gerasimovski --- board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c index 2be2b64..cff18dc 100644 --- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c +++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c @@ -91,8 +91,10 @@ int board_early_init_f(void) qrio_prstcfg(WCOM_CLIPS_RST, PRSTCFG_POWUP_UNIT_RST); qrio_prst(WCOM_CLIPS_RST, false, false); #endif + + /* deasset debug phy reset only if piggy is present */ qrio_prstcfg(KM_DBG_ETH_RST, PRSTCFG_POWUP_UNIT_CORE_RST); - qrio_prst(KM_DBG_ETH_RST, false, false); + qrio_prst(KM_DBG_ETH_RST, !qrio_get_pgy_pres_pin(), false); i2c_deblock_gpio_cfg(); -- 1.8.3.1
[PATCH 04/18] km: qrio: add function to read PGY_PRES pin status
It is necessary to read the status of the PGY_PRES pin
so that u-boot can react accordingly.
Signed-off-by: Rainer Boschung
Signed-off-by: Aleksandar Gerasimovski
---
board/keymile/common/qrio.c | 13 +
board/keymile/common/qrio.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/board/keymile/common/qrio.c b/board/keymile/common/qrio.c
index ed5e472..89a9726 100644
--- a/board/keymile/common/qrio.c
+++ b/board/keymile/common/qrio.c
@@ -40,6 +40,19 @@ bool qrio_get_selftest_pin(void)
return (slftest & 1) > 0;
}
+#define BPRTH_OFF 0x04
+
+bool qrio_get_pgy_pres_pin(void)
+{
+ u8 pgy_pres;
+
+ void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+ pgy_pres = in_8(qrio_base + BPRTH_OFF);
+
+ return (pgy_pres & 0x80) > 0;
+}
+
int qrio_get_gpio(u8 port_off, u8 gpio_nr)
{
u32 gprt;
diff --git a/board/keymile/common/qrio.h b/board/keymile/common/qrio.h
index c341cd9..2b997d9 100644
--- a/board/keymile/common/qrio.h
+++ b/board/keymile/common/qrio.h
@@ -13,6 +13,7 @@
void show_qrio(void);
bool qrio_get_selftest_pin(void);
+bool qrio_get_pgy_pres_pin(void);
int qrio_get_gpio(u8 port_off, u8 gpio_nr);
void qrio_set_opendrain_gpio(u8 port_off, u8 gpio_nr, u8 val);
void qrio_set_gpio(u8 port_off, u8 gpio_nr, bool value);
--
1.8.3.1
