Re: [Question] TI's u-boot.img is built twice
Hi Masahiro On 21/09/23 21:06, Masahiro Yamada wrote: Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. I haven't added the fit,external-offset property in the binman.dtsi so it was not appended as external data and I did not find reason to. Is there any benefit in having the data appended than embedded? To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure -- Thanking You Neha Malcom Francis
[PATCH] net: zynq_gem: Update the MDC clock divisor in the probe function
MDC clock change needs to be done when the driver probe function
is called as mdio is enabled at probe and not when the ethernet starts.
Setup the MDC clock at the probe itself.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/net/zynq_gem.c | 73 +++---
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index f3cdfb0275..f7a7897d9c 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -321,11 +321,38 @@ static int zynq_gem_setup_mac(struct udevice *dev)
return 0;
}
+static u32 gem_mdc_clk_div(struct zynq_gem_priv *priv)
+{
+ u32 config;
+ unsigned long pclk_hz;
+
+ pclk_hz = clk_get_rate(>pclk);
+ if (pclk_hz <= 2000)
+ config = GEM_MDC_SET(GEM_CLK_DIV8);
+ else if (pclk_hz <= 4000)
+ config = GEM_MDC_SET(GEM_CLK_DIV16);
+ else if (pclk_hz <= 8000)
+ config = GEM_MDC_SET(GEM_CLK_DIV32);
+ else if (pclk_hz <= 12000)
+ config = GEM_MDC_SET(GEM_CLK_DIV48);
+ else if (pclk_hz <= 16000)
+ config = GEM_MDC_SET(GEM_CLK_DIV64);
+ else if (pclk_hz <= 24000)
+ config = GEM_MDC_SET(GEM_CLK_DIV96);
+ else if (pclk_hz <= 32000)
+ config = GEM_MDC_SET(GEM_CLK_DIV128);
+ else
+ config = GEM_MDC_SET(GEM_CLK_DIV224);
+
+ return config;
+}
+
static int zynq_phy_init(struct udevice *dev)
{
- int ret;
+ int ret, val;
struct zynq_gem_priv *priv = dev_get_priv(dev);
struct zynq_gem_regs *regs_mdio = priv->mdiobase;
+ struct zynq_gem_regs *regs = priv->iobase;
const u32 supported = SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
@@ -333,6 +360,10 @@ static int zynq_phy_init(struct udevice *dev)
SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full;
+ val = gem_mdc_clk_div(priv);
+ if (val)
+ writel(val, >nwcfg);
+
/* Enable only MDIO bus */
writel(ZYNQ_GEM_NWCTRL_MDEN_MASK, _mdio->nwctrl);
@@ -360,35 +391,10 @@ static int zynq_phy_init(struct udevice *dev)
return phy_config(priv->phydev);
}
-static u32 gem_mdc_clk_div(struct zynq_gem_priv *priv)
-{
- u32 config;
- unsigned long pclk_hz;
-
- pclk_hz = clk_get_rate(>pclk);
- if (pclk_hz <= 2000)
- config = GEM_MDC_SET(GEM_CLK_DIV8);
- else if (pclk_hz <= 4000)
- config = GEM_MDC_SET(GEM_CLK_DIV16);
- else if (pclk_hz <= 8000)
- config = GEM_MDC_SET(GEM_CLK_DIV32);
- else if (pclk_hz <= 12000)
- config = GEM_MDC_SET(GEM_CLK_DIV48);
- else if (pclk_hz <= 16000)
- config = GEM_MDC_SET(GEM_CLK_DIV64);
- else if (pclk_hz <= 24000)
- config = GEM_MDC_SET(GEM_CLK_DIV96);
- else if (pclk_hz <= 32000)
- config = GEM_MDC_SET(GEM_CLK_DIV128);
- else
- config = GEM_MDC_SET(GEM_CLK_DIV224);
-
- return config;
-}
static int zynq_gem_init(struct udevice *dev)
{
- u32 i, nwconfig;
+ u32 i, nwconfig, nwcfg;
int ret;
unsigned long clk_rate = 0;
struct zynq_gem_priv *priv = dev_get_priv(dev);
@@ -494,8 +500,7 @@ static int zynq_gem_init(struct udevice *dev)
return -1;
}
- nwconfig = gem_mdc_clk_div(priv);
- nwconfig |= ZYNQ_GEM_NWCFG_INIT;
+ nwconfig = ZYNQ_GEM_NWCFG_INIT;
/*
* Set SGMII enable PCS selection only if internal PCS/PMA
@@ -509,19 +514,21 @@ static int zynq_gem_init(struct udevice *dev)
switch (priv->phydev->speed) {
case SPEED_1000:
- writel(nwconfig | ZYNQ_GEM_NWCFG_SPEED1000,
- >nwcfg);
+ nwconfig |= ZYNQ_GEM_NWCFG_SPEED1000;
clk_rate = ZYNQ_GEM_FREQUENCY_1000;
break;
case SPEED_100:
- writel(nwconfig | ZYNQ_GEM_NWCFG_SPEED100,
- >nwcfg);
+ nwconfig |= ZYNQ_GEM_NWCFG_SPEED100;
clk_rate = ZYNQ_GEM_FREQUENCY_100;
break;
case SPEED_10:
clk_rate = ZYNQ_GEM_FREQUENCY_10;
break;
}
+ nwcfg = readl(>nwcfg);
+ nwcfg |= nwconfig;
+ if (nwcfg)
+ writel(nwcfg, >nwcfg);
#ifdef CONFIG_ARM64
if (priv->interface == PHY_INTERFACE_MODE_SGMII &&
--
2.17.1
Re: [NEW FEATURE] RFC: Add Intel GMBUS support
+Simon Hi Eric, On Fri, Sep 22, 2023 at 6:10 AM Eric Schikschneit wrote: > > I have begun working on adding support for the Intel Graphics Management bus > to U-Boot. Currently the x86 bring up process (as explored on the Baytrail > series of Atom SOCs) relys on the Intel Video BIOS to do all setup and > configuration of the GPU. This method of adding video support works on > earlier versions of the silicon. With later versions I have found that the > OEM BIOS needs to capture the monitor data over the GMBUS in order to > initialize the GPU properly. I have logic analyzer captures available for > anyone who is curious. My purpose for this patch is a skeleton placeholder > that I will be working from, and I am asking for community collaboration with > this. I have hardware available for testing as needed, and some details can > be provided upon request. Would you share the documentation that describes the Intel GM bus, if publicly available? Based on the info you provided, did you mean with later new revision BayTrail chips, the video bios initialization is not enough in U-Boot? AFAIU, the U-Boot BayTrail support relies on Intel FSP to do any chipset-specific work, including the video bios setup. Regards, Bin
Re: [PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL
On 2023/9/21 22:47, Eugen Hristev wrote: On 8/1/23 10:28, Eugen Hristev wrote: This series adds support for DFU in SPL for rockchip rk3588 on rock5b board. Namely, when SPL is loaded via rockusb (thus via USB), having the `same-as-spl` boot order item, after having detected that it was loaded from USB, it will lookup the gadget USB node in DT and boot via DFU. Some changes were required namely: - DFU needs environment, hence adding environment variables into DFU - added bootph-all to nodes such that they are available in SPL - insert gadget into boot order I had to port one patch for DWC3 from Linux, and include in this series the patches that are floating from Venkatesh that fixup the DWC3 (https://marc.info/?l=u-boot=168351919807081=2 ) I know that Marek NAKed them and I am fine with it, I am not trying to sneak in any patches, they are not to be merged, also this patch `usb: dwc3: Increase DWC3 controller halt timeout` is in the same bucket so Marek you can NAK this one as well, no problem, I am just sending out all the series so maybe the rockchip part for the gadget can be picked up and if people want to use the DFU SPL gadget can also manually pick the DWC3 patches. The branch with all the patches is available here : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot Thanks! Changes in v2: - rebased on latest upstream which caused a change in the config patch. Eugen Hristev (7): rockchip: allow env defines for SPL build usb: dwc3: Increase DWC3 controller halt timeout ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes ARM: mach-rockchip: spl-boot-order: add possibility to DFU ARM: mach-rockchip: rk3588: add gadget device to the boot order rockchip: rk3588: prepare env for DFU configs: rockchip: rock5b-rk3588: enable DFU and related configs Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 + arch/arm/mach-rockchip/rk3588/rk3588.c | 1 + arch/arm/mach-rockchip/spl-boot-order.c | 3 +++ configs/rock5b-rk3588_defconfig | 18 +++--- drivers/usb/dwc3/core.c | 32 +++-- drivers/usb/dwc3/gadget.c | 20 +++- drivers/usb/dwc3/gadget.h | 14 +++ include/configs/rk3588_common.h | 9 ++- include/configs/rockchip-common.h | 4 9 files changed, 76 insertions(+), 31 deletions(-) Hello Kever, I see in patchwork this series is marked as 'Changes requested'. Do you wish to tell me which are the changes you requested, as I did not see anything in your replies. I am interested to see the patches related to rockchip (not the DWC3), if it's fine for you to merge them. Hi Eugen, For rockchip platform part is fine to me, but as a patchset, the dwc3 part is NAKed by Marek, so patch set not able to merge. If rockchip part can work without dwc3 change, you can send a separate patch set for it, so that I can merge it. Thanks, - Kever Thanks, Eugen
[PATCH 2/3] board: Remove essentially empty board files and Makefiles
As part of reviewing a new platform, Daniel Schwierzeck noted that we can have an empty Makefile in the board directory and don't need an empty board.c file as well. Further with further cleanup in the Makefile we can now omit the Makefile entirely. Remove a number of now unnecessary board.c and Makefiles. Signed-off-by: Tom Rini --- board/altera/arria10-socdk/Makefile | 5 - board/altera/arria10-socdk/socfpga.c | 6 -- board/altera/arria5-socdk/Makefile| 7 --- board/altera/arria5-socdk/socfpga.c | 5 - board/altera/cyclone5-socdk/Makefile | 7 --- board/altera/cyclone5-socdk/socfpga.c | 5 - board/altera/stratix10-socdk/Makefile | 7 --- board/altera/stratix10-socdk/socfpga.c| 7 --- board/aries/mcvevk/Makefile | 7 --- board/aries/mcvevk/socfpga.c | 5 - board/aspeed/evb_ast2500/Makefile | 1 - board/aspeed/evb_ast2500/evb_ast2500.c| 5 - board/aspeed/evb_ast2600/Makefile | 1 - board/aspeed/evb_ast2600/evb_ast2600.c| 5 - board/broadcom/bcm968380gerg/Makefile | 3 --- board/broadcom/bcm968380gerg/bcm968380gerg.c | 6 -- board/broadcom/bcm968380gerg/board.c | 6 -- board/comtrend/ar5315u/Makefile | 3 --- board/comtrend/ar5315u/ar-5315u.c | 6 -- board/comtrend/ar5387un/Makefile | 3 --- board/comtrend/ar5387un/ar-5387un.c | 6 -- board/comtrend/ct5361/Makefile| 3 --- board/comtrend/ct5361/ct-5361.c | 6 -- board/comtrend/vr3032u/Makefile | 3 --- board/comtrend/vr3032u/vr-3032u.c | 6 -- board/comtrend/wap5813n/Makefile | 3 --- board/comtrend/wap5813n/wap-5813n.c | 6 -- board/devboards/dbm-soc1/Makefile | 5 - board/devboards/dbm-soc1/socfpga.c| 5 - board/ebv/socrates/Makefile | 7 --- board/ebv/socrates/socfpga.c | 5 - board/edgeble/neural-compute-module-2/Makefile| 7 --- board/edgeble/neural-compute-module-2/neu2.c | 4 board/edgeble/neural-compute-module-6/Makefile| 7 --- board/edgeble/neural-compute-module-6/neu6.c | 4 board/efi/efi-x86_app/Makefile| 5 - board/efi/efi-x86_app/app.c | 6 -- board/emulation/qemu-x86/Makefile | 5 - board/emulation/qemu-x86/qemu-x86.c | 0 board/engicam/px30_core/Makefile | 7 --- board/engicam/px30_core/px30_core.c | 4 board/geekbuying/geekbox/Makefile | 5 - board/geekbuying/geekbox/geekbox.c| 6 -- board/google/chromebook_link/Makefile | 13 - board/google/chromebook_link/link.c | 6 -- board/google/chromebook_samus/Makefile| 5 - board/google/chromebook_samus/samus.c | 6 -- board/google/chromebox_panther/Makefile | 5 - board/google/chromebox_panther/panther.c | 6 -- board/hardkernel/odroid_m1/Makefile | 3 --- board/hardkernel/odroid_m1/odroid_m1.c| 1 - board/huawei/hg556a/Makefile | 3 --- board/huawei/hg556a/hg556a.c | 6 -- board/intel/agilex-socdk/Makefile | 7 --- board/intel/agilex-socdk/socfpga.c| 7 --- board/intel/bayleybay/Makefile| 1 - board/intel/bayleybay/bayleybay.c | 7 --- board/intel/n5x-socdk/Makefile| 7 --- board/intel/n5x-socdk/socfpga.c | 7 --- board/is1/Makefile| 5 - board/is1/socfpga.c | 4 board/mediatek/mt7620/Makefile| 3 --- board/mediatek/mt7620/board.c | 6 -- board/mediatek/mt7621/Makefile| 3 --- board/mediatek/mt7621/board.c | 6 -- board/mediatek/mt7628/Makefile| 3 --- board/mediatek/mt7628/board.c | 8 board/mqmaker/miqi_rk3288/Makefile| 7 --- board/mqmaker/miqi_rk3288/miqi-rk3288.c | 4 board/netgear/cg3100d/Makefile| 3 --- board/netgear/cg3100d/cg3100d.c | 6 -- board/pine64/quartz64_rk3566/Makefile | 3 --- board/pine64/quartz64_rk3566/quartz64-rk3566.c| 1 - board/qualcomm/dragonboard845c/Makefile | 9 - board/qualcomm/dragonboard845c/dragonboard845c.c | 9 -
[PATCH 3/3] exynos: Cleanup exynos_init
- None of the callers perform error checking and based on the non-empty
versions of this function, there's no checking to be done, so make
this a void.
- Add a default weak version of the function.
- Remove the empty versions of exynos_init now that we have a weak
version.
Signed-off-by: Tom Rini
---
arch/arm/mach-exynos/include/mach/board.h | 2 +-
board/samsung/axy17lte/Makefile | 3 ---
board/samsung/axy17lte/axy17lte.c | 11 ---
board/samsung/common/board.c | 8 +++-
board/samsung/common/exynos5-dt.c | 5 -
board/samsung/espresso7420/Makefile | 6 --
board/samsung/espresso7420/espresso7420.c | 13 -
board/samsung/odroid/odroid.c | 4 +---
board/samsung/origen/origen.c | 5 -
board/samsung/trats/trats.c | 14 +-
board/samsung/trats2/trats2.c | 4 +---
board/samsung/universal_c210/universal.c | 4 +---
12 files changed, 16 insertions(+), 63 deletions(-)
delete mode 100644 board/samsung/axy17lte/Makefile
delete mode 100644 board/samsung/axy17lte/axy17lte.c
delete mode 100644 board/samsung/espresso7420/Makefile
delete mode 100644 board/samsung/espresso7420/espresso7420.c
diff --git a/arch/arm/mach-exynos/include/mach/board.h
b/arch/arm/mach-exynos/include/mach/board.h
index 44ebdb829b20..a167f967933f 100644
--- a/arch/arm/mach-exynos/include/mach/board.h
+++ b/arch/arm/mach-exynos/include/mach/board.h
@@ -11,7 +11,7 @@
* Exynos baord specific changes for
* board_init
*/
-int exynos_init(void);
+void exynos_init(void);
/*
* Exynos board specific changes for
diff --git a/board/samsung/axy17lte/Makefile b/board/samsung/axy17lte/Makefile
deleted file mode 100644
index 4e11f289dcee..
--- a/board/samsung/axy17lte/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-obj-y += axy17lte.o
diff --git a/board/samsung/axy17lte/axy17lte.c
b/board/samsung/axy17lte/axy17lte.c
deleted file mode 100644
index c38297a05bab..
--- a/board/samsung/axy17lte/axy17lte.c
+++ /dev/null
@@ -1,11 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Samsung A5Y17 and A3Y17 LTE boards based on Exynos 7880 and Exynos 7870 SoCs
- */
-
-#include
-
-int exynos_init(void)
-{
- return 0;
-}
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 663d7ca991bc..5a71982775d0 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -43,6 +43,10 @@ __weak int exynos_early_init_f(void)
return 0;
}
+__weak void exynos_init(void)
+{
+}
+
__weak int exynos_power_init(void)
{
return 0;
@@ -113,7 +117,9 @@ int board_init(void)
gd->ram_size -= size;
gd->bd->bi_dram[CONFIG_NR_DRAM_BANKS - 1].size -= size;
#endif
- return exynos_init();
+ exynos_init();
+
+ return 0;
}
int dram_init(void)
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index 726b7f0667a6..72e0cecb040f 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -37,11 +37,6 @@
DECLARE_GLOBAL_DATA_PTR;
-int exynos_init(void)
-{
- return 0;
-}
-
static int exynos_set_regulator(const char *name, uint uv)
{
struct udevice *dev;
diff --git a/board/samsung/espresso7420/Makefile
b/board/samsung/espresso7420/Makefile
deleted file mode 100644
index bb882eaa254e..
--- a/board/samsung/espresso7420/Makefile
+++ /dev/null
@@ -1,6 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2016 Samsung Electronics
-# Thomas Abraham
-
-obj-y += espresso7420.o
diff --git a/board/samsung/espresso7420/espresso7420.c
b/board/samsung/espresso7420/espresso7420.c
deleted file mode 100644
index 9f6fa897477a..
--- a/board/samsung/espresso7420/espresso7420.c
+++ /dev/null
@@ -1,13 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Espresso7420 board file
- * Copyright (C) 2016 Samsung Electronics
- * Thomas Abraham
- */
-
-#include
-
-int exynos_init(void)
-{
- return 0;
-}
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 39a60e4ad295..2c5bafae7f00 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -422,11 +422,9 @@ int exynos_early_init_f(void)
return 0;
}
-int exynos_init(void)
+void exynos_init(void)
{
board_gpio_init();
-
- return 0;
}
int exynos_power_init(void)
diff --git a/board/samsung/origen/origen.c b/board/samsung/origen/origen.c
index 7a91f448969b..ddf6a2b72fa5 100644
--- a/board/samsung/origen/origen.c
+++ b/board/samsung/origen/origen.c
@@ -12,11 +12,6 @@
#include
#include
-int exynos_init(void)
-{
- return 0;
-}
-
int board_usb_init(int index, enum usb_init_type init)
{
return 0;
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 1608d60dd8db..6a3e5b29b989 100644
---
[PATCH 1/3] Makefile: Allow for board directories to not have a Makefile
It is entirely possible at this point to have platforms in U-Boot that do not have board-specific C code (just Kconfig or environment) and so make it optional to have to descend in to and then build in the board directory. Signed-off-by: Tom Rini --- Makefile | 2 +- scripts/Makefile.spl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 9be24c4ec613..5e27bceb8e6c 100644 --- a/Makefile +++ b/Makefile @@ -877,7 +877,7 @@ libs-$(CONFIG_UT_ENV) += test/env/ libs-$(CONFIG_UT_OPTEE) += test/optee/ libs-$(CONFIG_UT_OVERLAY) += test/overlay/ -libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/) +libs-y += $(if $(wildcard $(srctree)/board/$(BOARDDIR)/Makefile),board/$(BOARDDIR)/) libs-y := $(sort $(libs-y)) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 15ac87286d5a..32f4384657b1 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -96,7 +96,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) -libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/) +libs-y += $(if $(wildcard $(srctree)/board/$(BOARDDIR)/Makefile),board/$(BOARDDIR)/) libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/ ifeq ($(CONFIG_TPL_BUILD),y) -- 2.34.1
Re: [PATCH v7 2/3] x86: coreboot: Drop USB init on startup
On Thu, Sep 21, 2023 at 9:37 PM Simon Glass wrote: > > This is very annoying as it is quite slow on many machines. Also, U-Boot > has an existing 'preboot' mechanism to enable this feature if desired. > > Drop this code so that it is possible to choose whether to init USB or > not. > > Use the existing USE_PREBOOT mechanism instead. > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Add docs about how USB keyboard works on coreboot > > Changes in v5: > - Make use of the uSE_PREBOOT mechanism > > arch/x86/cpu/coreboot/Kconfig| 1 + > arch/x86/cpu/coreboot/coreboot.c | 4 > doc/board/coreboot/coreboot.rst | 7 +++ > 3 files changed, 8 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng series applied to u-boot-x86/next, thanks!
Re: [PATCH v7 1/3] fixup: Move python control earlier in Makefile
On Thu, Sep 21, 2023 at 9:37 PM Simon Glass wrote: > > Move this control into the common area of the main Makefile, so it > applies to non-build rules as well. This allows 'make mrproper' to handle > python files as it should. > > This should be squashed into: > >65a33eba10d Allow Python packages to be dropped > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Add new fixup patch to move python control earlier in Makefile > > Makefile | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > squashed into "65a33eba10d Allow Python packages to be dropped" on u-boot-x86/next, thanks!
Re: [PATCH] RFT: mips: implement __udivdi3
On Thu, Sep 21, 2023 at 3:42 PM Daniel Schwierzeck
wrote:
> I played around a bit and following simplified code compiles on various
> MIPS32 and MIPS64 boards. (E.g. "echo CONFIG_FS_SQUASHFS=y >>
> configs/malta[|64|el|64el]_defconfig && make malta[|64|el|64el]_defconfig")
>
>
>
> /* SPDX-License-Identifier: GPL-2.0 */
>
> #include "libgcc.h"
>
> #if BITS_PER_LONG == 32
>
> #include
>
> long long __udivdi3(long long u, word_type b)
> {
> long long ret = u;
>
> __div64_32(, b);
> return ret;
> }
>
> #endif /* BITS_PER_LONG == 32 */
>
> What do you think?
Looks good to me!
You can just modify the patch, sign off and apply,
I guess? Go ahead!
Yours,
Linus Walleij
Re: [PATCH 1/1] riscv: set fdtfile on VisionFive 2
On Thu, 2023-09-07 at 13:21, Heinrich Schuchardt wrote:
> Multiple revisions of the StarFive VisionFive 2 board exist. They can be
> identified by reading their EEPROM.
>
> Linux uses two differently named device-tree files. To load the correct
> device-tree we need to set $fdtfile to the device-tree file name that
> matches the board revision.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Leo Yu-Chi Liang
Tested-by: Milan P. Stanić
> ---
> arch/riscv/Kconfig| 1 +
> .../visionfive2/starfive_visionfive2.c| 43 ++-
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 6771d8d919..1c62c2345b 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -26,6 +26,7 @@ config TARGET_SIFIVE_UNMATCHED
>
> config TARGET_STARFIVE_VISIONFIVE2
> bool "Support StarFive VisionFive2 Board"
> + select BOARD_LATE_INIT
>
> config TARGET_TH1520_LPI4A
> bool "Support Sipeed's TH1520 Lichee PI 4A Board"
> diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
> b/board/starfive/visionfive2/starfive_visionfive2.c
> index d609262b67..05d8d2d657 100644
> --- a/board/starfive/visionfive2/starfive_visionfive2.c
> +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> @@ -5,14 +5,20 @@
> */
>
> #include
> -#include
> -#include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> #include
>
> #define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
> #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
> +#define FDTFILE_VISIONFIVE2_1_2A \
> + "starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
> +#define FDTFILE_VISIONFIVE2_1_3B \
> + "starfive/jh7110-starfive-visionfive-2-v1.3b.dtb"
>
> /* enable U74-mc hart1~hart4 prefetcher */
> static void enable_prefetcher(void)
> @@ -33,6 +39,31 @@ static void enable_prefetcher(void)
> }
> }
>
> +/**
> + * set_fdtfile() - set the $fdtfile variable based on the board revision
> + */
> +static void set_fdtfile(void)
> +{
> + u8 version;
> + const char *fdtfile;
> +
> + version = get_pcb_revision_from_eeprom();
> + switch (version) {
> + case 'a':
> + case 'A':
> + fdtfile = FDTFILE_VISIONFIVE2_1_2A;
> + break;
> +
> + case 'b':
> + case 'B':
> + default:
> + fdtfile = FDTFILE_VISIONFIVE2_1_3B;
> + break;
> + };
> +
> + env_set("fdtfile", fdtfile);
> +}
> +
> int board_init(void)
> {
> enable_caches();
> @@ -41,6 +72,14 @@ int board_init(void)
> return 0;
> }
>
> +int board_late_init(void)
> +{
> + if (CONFIG_IS_ENABLED(ID_EEPROM))
> + set_fdtfile();
> +
> + return 0;
> +}
> +
> void *board_fdt_blob_setup(int *err)
> {
> *err = 0;
Re: [PULL] u-boot-riscv/master
On Thu, Sep 21, 2023 at 09:36:01AM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit b9b83a86f0e84e837191db120c279a9cc0e3434b: > > Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh > (2023-09-17 09:25:42 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 43177705ab29ed1ccca970096de1ef3c6095e7e6: > > board: visionfive2: Fixup memory size passed to kernel (2023-09-20 20:30:30 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/1 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] xilinx patches for v2024.01-rc1 v2
On Thu, Sep 21, 2023 at 02:56:59PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these patches to your next branch. > I am sending it as v2 in spite of v1 didn't really went through. I created > tag but CI failed because of sandbox CI trace failure. After fixing it and > reviewing by Simon I am adding it to be able to extend ofnode functions for > getting functionality for our SOCs. All non Xilinx patches are reviewed > mostly by Simon. > > There are other pending changes which are still under review which should go > to v2024.01 but I wanted to get this part done because amount of patches is > bigger than I would like have. > > I was thinking about sending cmd/flash_is_unloacked fix to 2023.07 but it > looks like none is actually using spi locking that's why it shouldn't be a > problem to fix in 2024.01. But feel free to pick it up to master if you > like. > > Thanks, > Michal > > > The following changes since commit c58ee1c9946a1550b1f6fee2b25da9ecc89baf71: > > Merge branch '2023-09-19-tidy-up-some-kconfig-options' into next > (2023-09-19 17:44:18 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2024.01-rc1-v2 > > for you to fetch changes up to a3ade3dae4d93f9b5282ddb4885d69161729ec6d: > > spi: zynqmp_qspi: Workaround for small data cache issue (2023-09-21 > 13:20:12 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-riscv/next
On Thu, Sep 21, 2023 at 09:28:46AM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit c58ee1c9946a1550b1f6fee2b25da9ecc89baf71: > > Merge branch '2023-09-19-tidy-up-some-kconfig-options' into next > (2023-09-19 17:44:18 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git next > > for you to fetch changes up to 90602e779d3ae3bd02faae0eb40b4fcefec419f7: > > riscv: dts: starfive: generate u-boot-spl.bin.normal.out (2023-09-20 > 21:05:16 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/17779 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] dt-bindings: mtd: Add a schema for binman
Binman[1] is a tool for creating firmware images. It allows you to
combine various binaries and place them in an output file.
Binman uses a DT schema to describe an image, in enough detail that
it can be automatically built from component parts, disassembled,
replaced, listed, etc.
Images are typically stored in flash, which is why this binding is
targeted at mtd. Previous discussion is at [2] [3].
[1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html
[2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/
[3] https://www.spinics.net/lists/devicetree/msg626149.html
Signed-off-by: Simon Glass
---
.../bindings/mtd/partitions/binman.yaml | 50 +++
.../bindings/mtd/partitions/binman/entry.yaml | 61 +++
.../bindings/mtd/partitions/partitions.yaml | 1 +
MAINTAINERS | 5 ++
4 files changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index 00..c792d5a37b700a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman firmware layout
+
+maintainers:
+ - Simon Glass
+
+description: |
+ The binman node provides a layout for firmware, used when packaging firmware
+ from multiple projects. For now it just supports a very simple set of
+ features, as a starting point for discussion.
+
+ Documentation for Binman is available at:
+
+ https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
+
+ with the current image-description format at:
+
+
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
+
+properties:
+ compatible:
+const: u-boot,binman
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+firmware {
+ binman {
+compatible = "u-boot,binman";
+
+u-boot {
+ size = <0xa>;
+};
+
+atf-bl31 {
+ offset = <0x10>;
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
new file mode 100644
index 00..8003eb4f1a994f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman/entry.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman entry
+
+maintainers:
+ - Simon Glass
+
+description: |
+ The entry node specifies a single entry in the firmware.
+
+ Entries have a specific type, such as "u-boot" or "atf-bl31". If the type
+ is missing, the name is used as the type.
+
+ Note: This definition is intended to be hierarchical, so that entries can
+ appear in other entries. Schema for that is TBD.
+
+properties:
+ $nodename:
+pattern: "^[-a-z]+(-[0-9]+)?$"
+
+ type:
+$ref: /schemas/types.yaml#/definitions/string
+
+ offset:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ Provides the offset of this entry from the start of its parent section.
+ If this is omitted, Binman will determine this by packing the enclosing
+ section according to alignment rules, etc.
+
+ size:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ Provides the size of this entry in bytes. If this is omitted, Binman will
+ use the content size, along with any alignment information, to determine
+ the size of the entry.
+
+additionalProperties: false
+
+examples:
+ - |
+firmware {
+ binman {
+compatible = "u-boot,binman";
+
+u-boot {
+ size = <0xa>;
+};
+
+second-area {
+ type = "atf-bl31";
+ offset = <0x10>;
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
index 1dda2c80747bd7..849fd15d085ccc 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -15,6 +15,7 @@ maintainers:
oneOf:
- $ref: arm,arm-firmware-suite.yaml
+ - $ref: binman.yaml
- $ref: brcm,bcm4908-partitions.yaml
- $ref: brcm,bcm947xx-cfe-partitions.yaml
- $ref:
[PATCH 5/5] arm64: dts: imx8mp: Add DT overlay describing i.MX8MP DHCOM SoM rev.100
The current imx8mp-dhcom-som.dtsi describes production rev.200 SoM,
add DT overlay which reinstates rev.100 SoM description to permit
prototype rev.100 SoMs to be used until they get phased out.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Algapally Santosh Sagar
Cc: Fabio Estevam
Cc: Mayuresh Chitale
Cc: Oleksandr Suvorov
Cc: Ovidiu Panait
Cc: Roger Quadros
Cc: Simon Glass
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
arch/arm/dts/Makefile | 2 +
.../dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 10 ++
.../dts/imx8mp-dhcom-som-overlay-rev100.dts | 120 ++
arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 8 +-
board/dhelectronics/dh_imx8mp/spl.c | 16 +++
5 files changed, 152 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
create mode 100644 arch/arm/dts/imx8mp-dhcom-som-overlay-rev100.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a116207b473..f05aa3d21f6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1042,11 +1042,13 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-phanbell.dtb \
imx8mp-beacon-kit.dtb \
imx8mp-data-modul-edm-sbc.dtb \
+ imx8mp-dhcom-som-overlay-rev100.dtbo \
imx8mp-dhcom-som-overlay-eth1xfast.dtbo \
imx8mp-dhcom-som-overlay-eth2xfast.dtbo \
imx8mp-dhcom-pdk-overlay-eth2xfast.dtbo \
imx8mp-dhcom-pdk2.dtb \
imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-rev100.dtbo \
imx8mp-evk.dtb \
imx8mp-icore-mx8mp-edimm2.2.dtb \
imx8mp-msc-sm2s.dtb \
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
new file mode 100644
index 000..f27e6429abe
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+ {
+ reg = <7>;
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-som-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-som-overlay-rev100.dts
new file mode 100644
index 000..5d9a00c9429
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-som-overlay-rev100.dts
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include
+#include
+
+#include "imx8mp-pinfunc.h"
+
+ {
+ reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+};
+
+ { /* EEPROM with EQoS MAC address */
+ compatible = "atmel,24c02";
+ pagesize = <16>;
+};
+
+ { /* EEPROM with FEC MAC address */
+ compatible = "atmel,24c02";
+ pagesize = <16>;
+};
+
+ { /* SMSC LAN8740Ai */
+ pinctrl-0 = <_ethphy0 _ioexp>;
+ reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+};
+
+ { /* Micrel KSZ9131RNXI */
+ pinctrl-0 = <_ethphy0 _ioexp>;
+ reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ adc@48 {
+ compatible = "ti,tla2024";
+ interrupts-extended;
+ };
+};
+
+ {
+ status = "disabled";
+};
+
+_eth_vio {
+ gpio = < 10 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <_enet_vio>;
+ pinctrl-names = "default";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_rtc>;
+ interrupts-extended = < 5 IRQ_TYPE_LEVEL_LOW>;
+};
+
+ {
+ bluetooth {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart2_bt>;
+ shutdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+_dwc3_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb0_vbus>;
+};
+
+ {
+ pinctrl-0 = <_usdhc1 _usdhc1_wl_reg_en>;
+ pinctrl-1 = <_usdhc1_100mhz _usdhc1_wl_reg_en>;
+ pinctrl-2 = <_usdhc1_200mhz _usdhc1_wl_reg_en>;
+};
+
+ {
+ pinctrl-0 = <_hog_base
+_dhcom_a _dhcom_b _dhcom_c
+_dhcom_d _dhcom_e _dhcom_f
+_dhcom_g _dhcom_h _dhcom_i
+_dhcom_j _dhcom_k _dhcom_l
+/* GPIO_M is connected to CLKOUT2 */
+_dhcom_int>;
+
+ pinctrl_enet_vio: dhcom-enet-vio-grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_RESET_B__GPIO2_IO100x22
+ >;
+ };
+
+ pinctrl_rtc: dhcom-rtc-grp {
+ fsl,pins = <
+ /* RTC_#INT Interrupt */
+ MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05
0x41c6
+ >;
+ };
+
+ pinctrl_uart2_bt: dhcom-uart2-bt-grp {
+ fsl,pins = <
+ /* BT_REG_EN */
+ MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12 0x144
+ >;
+ };
+
+ pinctrl_usb0_vbus: dhcom-usb0-grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO10__USB1_OTG_ID0x0
+ >;
+ };
[PATCH 4/5] arm64: dts: imx8mp: Drop i.MX8MP DHCOM rev.100 PHY address workaround from PDK3 DT
In case the i.MX8MP DHCOM rev.100 has been populated on the PDK3
carrier board, the on-SoM PHY PHYAD1 signal has been pulled high
by the carrier board and changed the PHY MDIO address from 5 to 7.
This has been fixed on production rev.200 SoM by additional buffer
on the SoM PHYAD/LED signals, remove the workaround.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Algapally Santosh Sagar
Cc: Fabio Estevam
Cc: Mayuresh Chitale
Cc: Oleksandr Suvorov
Cc: Ovidiu Panait
Cc: Roger Quadros
Cc: Simon Glass
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
arch/arm/dts/imx8mp-dhcom-pdk3.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3.dts
index c5f0607f43b..867d238f2b5 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3.dts
@@ -227,10 +227,6 @@
};
};
- {
- reg = <7>;
-};
-
{ /* Second ethernet */
pinctrl-0 = <_fec_rgmii>;
phy-handle = <>;
--
2.40.1
[PATCH 3/5] arm64: dts: imx8mp: Update i.MX8MP DHCOM SoM DT to production rev.200
The current imx8mp-dhcom-som.dtsi describes prototype rev.100 SoM,
update the DT to describe production rev.200 SoM which brings the
following changes:
- Fast SoC GPIOs exposed on the SoM edge connector
- Slow GPIOs like component resets moved to I2C GPIO expander
- ADC upgraded from TLA2024 to ADS1015 with conversion interrupt
- EEPROM size increased from 256 B to 4 kiB
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Algapally Santosh Sagar
Cc: Fabio Estevam
Cc: Mayuresh Chitale
Cc: Oleksandr Suvorov
Cc: Ovidiu Panait
Cc: Roger Quadros
Cc: Simon Glass
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
arch/arm/dts/imx8mp-dhcom-som.dtsi| 176 +++---
arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 24 +++-
configs/imx8mp_dhcom_pdk3_defconfig | 1 +
3 files changed, 152 insertions(+), 49 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-som.dtsi
b/arch/arm/dts/imx8mp-dhcom-som.dtsi
index 9fd8bce8065..ea2a567447a 100644
--- a/arch/arm/dts/imx8mp-dhcom-som.dtsi
+++ b/arch/arm/dts/imx8mp-dhcom-som.dtsi
@@ -25,9 +25,7 @@
reg_eth_vio: regulator-eth-vio {
compatible = "regulator-fixed";
- gpio = < 10 GPIO_ACTIVE_LOW>;
- pinctrl-0 = <_enet_vio>;
- pinctrl-names = "default";
+ gpio = < 2 GPIO_ACTIVE_LOW>;
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <330>;
@@ -49,6 +47,14 @@
startup-delay-us = <100>;
vin-supply = <>;
};
+
+ reg_vdd_3p3v_awo: regulator-vdd-3p3v-awo { /* VDD_3V3_AWO */
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "VDD_3P3V_AWO";
+ };
};
_0 {
@@ -104,7 +110,7 @@
reg = <0>;
reset-assert-us = <1000>;
reset-deassert-us = <1000>;
- reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
/* Non-default PHY population option. */
status = "disabled";
};
@@ -120,7 +126,7 @@
reg = <5>;
reset-assert-us = <1000>;
reset-deassert-us = <1000>;
- reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
/* Default PHY population option. */
status = "okay";
};
@@ -320,8 +326,9 @@
};
adc@48 {
- compatible = "ti,tla2024";
+ compatible = "ti,ads1015";
reg = <0x48>;
+ interrupts-extended = < 7 IRQ_TYPE_EDGE_FALLING>;
#address-cells = <1>;
#size-cells = <0>;
@@ -368,24 +375,40 @@
};
eeprom0: eeprom@50 {/* EEPROM with EQoS MAC address */
- compatible = "atmel,24c02";
- pagesize = <16>;
+ compatible = "atmel,24c32"; /* M24C32-D */
+ pagesize = <32>;
reg = <0x50>;
};
rv3032: rtc@51 {
compatible = "microcrystal,rv3032";
reg = <0x51>;
- interrupts-extended = < 5 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <_rtc>;
+ interrupts-extended = < 3 IRQ_TYPE_EDGE_FALLING>;
};
eeprom1: eeprom@53 {/* EEPROM with FEC MAC address */
- compatible = "atmel,24c02";
- pagesize = <16>;
+ compatible = "atmel,24c32"; /* M24C32-D */
+ pagesize = <32>;
reg = <0x53>;
};
+
+ ioexp: gpio@74 {
+ compatible = "nxp,pca9539";
+ reg = <0x74>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts-extended = < 20 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ioexp>;
+
+ gpio-line-names =
+ "BT_REG_EN", "WL_REG_EN", "VIO_SWITCHED_#EN",
"RTC_#INT",
+ "ENET_QOS_#RST", "RGB_OSZ_ENABLE", "USB1_ID",
"ADC_ALTER_RDY",
+ "DHCOM-W", "DHCOM-V", "DHCOM-U", "DHCOM-T",
+ "BT_HOST_WAKE", "BT_DEV_WAKE", "", "";
+ };
};
{
@@ -427,6 +450,23 @@
pinctrl-0 = <_uart2>;
uart-has-rtscts;
status = "okay";
+
+ /*
+* PLL1 at 80 MHz supplies UART2 root with 80 MHz clock,
+* which with 16x oversampling yields 5 Mbdps baud base,
+* which can be well divided by 5/4 to
[PATCH 2/5] arm64: dts: imx8mp: Switch to DT overlays for i.MX8MP DHCOM SoM
Add DT overlays to support additional DH i.MX8MP DHCOM SoM 660-100
population options with 1x or 2x RMII PHY mounted on PDK2 or PDK3
carrier boards.
Use SPL DTO support to apply matching SoM specific DTO to cater
for the SoM differences. Remove ad-hoc patching of control DT from
fdtdec_board_setup().
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Algapally Santosh Sagar
Cc: Fabio Estevam
Cc: Mayuresh Chitale
Cc: Oleksandr Suvorov
Cc: Ovidiu Panait
Cc: Roger Quadros
Cc: Simon Glass
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
arch/arm/dts/Makefile | 3 +
.../imx8mp-dhcom-pdk-overlay-eth2xfast.dts| 10 +
.../imx8mp-dhcom-som-overlay-eth1xfast.dts| 43
.../imx8mp-dhcom-som-overlay-eth2xfast.dts| 24 ++
arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 49
.../dh_imx8mp/imx8mp_dhcom_pdk2.c | 228 --
board/dhelectronics/dh_imx8mp/spl.c | 46
configs/imx8mp_dhcom_pdk3_defconfig | 3 +-
8 files changed, 177 insertions(+), 229 deletions(-)
create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk-overlay-eth2xfast.dts
create mode 100644 arch/arm/dts/imx8mp-dhcom-som-overlay-eth1xfast.dts
create mode 100644 arch/arm/dts/imx8mp-dhcom-som-overlay-eth2xfast.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7f..a116207b473 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1042,6 +1042,9 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-phanbell.dtb \
imx8mp-beacon-kit.dtb \
imx8mp-data-modul-edm-sbc.dtb \
+ imx8mp-dhcom-som-overlay-eth1xfast.dtbo \
+ imx8mp-dhcom-som-overlay-eth2xfast.dtbo \
+ imx8mp-dhcom-pdk-overlay-eth2xfast.dtbo \
imx8mp-dhcom-pdk2.dtb \
imx8mp-dhcom-pdk3.dtb \
imx8mp-evk.dtb \
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk-overlay-eth2xfast.dts
b/arch/arm/dts/imx8mp-dhcom-pdk-overlay-eth2xfast.dts
new file mode 100644
index 000..3b397776920
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk-overlay-eth2xfast.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+ { /* Micrel KSZ9131RNXI */
+ status = "disabled";
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-som-overlay-eth1xfast.dts
b/arch/arm/dts/imx8mp-dhcom-som-overlay-eth1xfast.dts
new file mode 100644
index 000..bb5a2b68175
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-som-overlay-eth1xfast.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include
+
+ {/* First ethernet */
+ pinctrl-0 = <_eqos_rmii>;
+ phy-handle = <>;
+ phy-mode = "rmii";
+
+ assigned-clock-parents = < IMX8MP_SYS_PLL1_266M>,
+< IMX8MP_SYS_PLL2_100M>,
+< IMX8MP_SYS_PLL2_50M>;
+ assigned-clock-rates = <0>, <1>, <5000>;
+};
+
+ {/* Micrel KSZ9131RNXI */
+ status = "disabled";
+};
+
+ {/* SMSC LAN8740Ai */
+ status = "okay";
+};
+
+ { /* Second ethernet -- HS connector not populated on 1x RMII PHY SoM */
+ status = "disabled";
+};
+
+/* No WiFi/BT chipset on this SoM variant. */
+
+ {
+ bluetooth {
+ status = "disabled";
+ };
+};
+
+ {
+ status = "disabled";
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-som-overlay-eth2xfast.dts
b/arch/arm/dts/imx8mp-dhcom-som-overlay-eth2xfast.dts
new file mode 100644
index 000..82dadcea96c
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-som-overlay-eth2xfast.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+#include "imx8mp-dhcom-som-overlay-eth1xfast.dts"
+
+/* Dual RMII 100/Full Fast ethernet on this SoM variant. */
+
+ { /* Second ethernet */
+ pinctrl-0 = <_fec_rmii>;
+ phy-handle = <>;
+ phy-mode = "rmii";
+ status = "okay";
+
+ assigned-clock-parents = < IMX8MP_SYS_PLL1_266M>,
+< IMX8MP_SYS_PLL2_100M>,
+< IMX8MP_SYS_PLL2_50M>,
+< IMX8MP_SYS_PLL2_50M>;
+ assigned-clock-rates = <0>, <1>, <5000>, <0>;
+};
+
+ {/* SMSC LAN8740Ai */
+ status = "okay";
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
index 59d31eebc3e..00e1db66568 100644
--- a/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
@@ -133,3 +133,52 @@
{
bootph-pre-ram;
};
+
+ {
+ itb {
+ fit {
+ images {
+ fdt-dto-imx8mp-dhcom-som-overlay-eth1xfast {
+ description =
"imx8mp-dhcom-som-overlay-eth1xfast";
+ type =
[PATCH 1/5] spl: fit: Add board level function to decide application of DTO
Add board-specific function used to indicate whether a DTO from fitImage
configuration node 'fdt' property DT and DTO list should be applied onto
the base DT or not applied.
This is useful in case of DTOs which implement e.g. different board revision
details, where such DTO should be applied on one board revision, and should
not be applied on another board revision.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Algapally Santosh Sagar
Cc: Fabio Estevam
Cc: Mayuresh Chitale
Cc: Oleksandr Suvorov
Cc: Ovidiu Panait
Cc: Roger Quadros
Cc: Simon Glass
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
common/spl/spl_fit.c | 23 ---
include/spl.h| 16
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 730639f7562..ed91ddd6b40 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -357,6 +357,11 @@ static bool os_takes_devicetree(uint8_t os)
}
}
+__weak int board_spl_fit_append_fdt_skip(const char *name)
+{
+ return 0; /* Do not skip */
+}
+
static int spl_fit_append_fdt(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector,
const struct spl_fit_info *ctx)
@@ -400,11 +405,23 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
void *tmpbuffer = NULL;
for (; ; index++) {
- node = spl_fit_get_image_node(ctx, FIT_FDT_PROP, index);
- if (node == -E2BIG) {
+ const char *str;
+
+ ret = spl_fit_get_image_name(ctx, FIT_FDT_PROP, index,
);
+ if (ret == -E2BIG) {
debug("%s: No additional FDT node\n", __func__);
+ ret = 0;
break;
- } else if (node < 0) {
+ } else if (ret < 0) {
+ continue;
+ }
+
+ ret = board_spl_fit_append_fdt_skip(str);
+ if (ret)
+ continue;
+
+ node = fdt_subnode_offset(ctx->fit, ctx->images_node,
str);
+ if (node < 0) {
debug("%s: unable to find FDT node %d\n",
__func__, index);
continue;
diff --git a/include/spl.h b/include/spl.h
index 92bcaa90a4a..60a432c4b15 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -895,6 +895,22 @@ void spl_perform_fixups(struct spl_image_info *spl_image);
*/
struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size);
+/**
+ * board_spl_fit_append_fdt_skip(): test whether DTO application should be
skipped
+ * @name: DTO node name within fitImage images node
+ *
+ * A board-specific function used to indicate whether a DTO from fitImage
+ * configuration node 'fdt' property DT and DTO list should be applied onto
+ * the base DT or not applied.
+ *
+ * This is useful in case of DTOs which implement e.g. different board revision
+ * details, where such DTO should be applied on one board revision, and should
+ * not be applied on another board revision.
+ *
+ * Return: 0 to indicate DTO is not skipped, all else to indicate DTO is
skipped.
+ */
+int board_spl_fit_append_fdt_skip(const char *name);
+
void board_boot_order(u32 *spl_boot_list);
void spl_save_restore_data(void);
#endif
--
2.40.1
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Rob, On Thu, 21 Sept 2023 at 07:59, Rob Herring wrote: > > On Tue, Sep 19, 2023 at 3:26 PM Simon Glass wrote: > > > > Hi Rob, > > > > On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > > > > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > > > > > Hi Rob, > > > > > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Jassi Brar > > > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass > > > > > > > wrote: > > > > > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > > > > > > > > > > > > > > > > > I beg to differ. Devicetree is more than just hardware > > > > > > > > > > > and always has > > > > > > > > > > > been. See, for example the /chosen and /options nodes. > > > > > > > > > > > > > > > > > > > > There are exceptions... > > > > > > > > > > > > > > > > > > > > > > > > > > > > We've been this over and over again and frankly it gets a bit > > > > > > > > > annoying. > > > > > > > > > It's called *DEVICE* tree for a reason. As Rob pointed out > > > > > > > > > there are > > > > > > > > > exceptions, but those made a lot of sense. Having arbitrary > > > > > > > > > internal ABI > > > > > > > > > stuff of various projects in the schema just defeats the > > > > > > > > > definition of a > > > > > > > > > spec. > > > > > > > > > > > > > > > > Our efforts should not just be about internal ABI, but working > > > > > > > > to > > > > > > > > provide a consistent configuration system for all firmware > > > > > > > > elements. > > > > > > > > > > > > > > > Sure, programmatically we can pass any data/info via DT, however > > > > > > > it is > > > > > > > only meant to map hardware features onto data structures. > > > > > > > > > > > > > > devicetree.org landing page > > > > > > > "The devicetree is a data structure for describing hardware." > > > > > > > > > > > > > > devicetree-specification-v0.3.pdf Chapter-2 Line-1 > > > > > > >"DTSpec specifies a construct called a devicetree to describe > > > > > > > system hardware." > > > > > > > > > > > > But it doesn't say that it describes *only* hardware. And it does > > > > > > describe more than just hardware. There is /chosen to specify > > > > > > firmware configuration and there are several examples of device tree > > > > > > bindings that describe non-discoverable firmware interfaces in the > > > > > > Linux tree. And it has been that way since the days of IEEE 1275. > > > > > > There are also bindings describing things like the firmware > > > > > > partition > > > > > > layout. > > > > > > > > > > Yes. The exact title for 1275[1] is: IEEE Standard for Boot > > > > > (Initialization Configuration) > > > > > Firmware: Core Requirements and Practices > > > > > > > > > > I see "configuration" in there. However, in the OF case, it's > > > > > generally how firmware configured the hardware and what it discovered. > > > > > That's a little different than telling the OS how to configure the > > > > > hardware which is what we do with FDT. > > > > > > > > For the /options node it says "The properties of this node are the > > > > system’s configuration variables." > > > > > > > > Then there is section 7.4.4 which has a large list of options which > > > > don't seem to be so narrowly defined. > > > > > > > > In any case, this is not quite the point, which IMO is that we need DT > > > > to support firmware use cases, whether or not a 29-year-old spec > > > > thought of it or not. In fact it is amazing to me how forward-looking > > > > Open Firmware was. > > > > > > > > > Then there's stuff that's how > > > > > to configure Linux which we try to reject. > > > > > > > > Fair enough: Linux has user-space for that. > > > > > > Yep, the question I usually ask is who needs to configure something > > > and what determines the config. Changing things with sysfs is much > > > easier than changing the DT provided by firmware. > > > > > > > > > > > > > Once we get into configuration of the OS/client (including u-boot), > > > > > making that an ABI is a lot harder and if we use DT for that, I don't > > > > > think it should be an ABI. > > > > > > > > > > > > If we want to digress from the spec, we need the majority of > > > > > > > developers to switch sides :) which is unlikely to happen and > > > > > > > rightly > > > > > > > so, imho. > > > > > > > > > > > > It isn't even clear what the spec is. There is the document you > > > > > > reference above, there are the yaml files at > > > > > > https://github.com/devicetree-org/dt-schema and then there are > > > > > > additional yaml files in the Linux tree. As far as I know it isn't > > > > > > written down anywhere that those are the only places where device > > > > > > tree > > > > > > bindings can live. > > > > > > > > > > There's not any restriction. >
Re: [PATCH] bmips: Add Inteno XG6846 board
On Thu, Sep 21, 2023 at 04:00:24PM +0200, Daniel Schwierzeck wrote: [snip] > I just tested it, you can simply add an empty board/inteno/xg6846/Makefile and > remove board/inteno/xg6846/xg6846.c. But you can also remove the Makefile. > Just the Kconfig and MAINTAINERS file are needed. An empty Makefile is OK, but no Makefile requires a bit more as we first try and include it unconditionally and then try and link in built-in.o. I'm poking at this now. -- Tom signature.asc Description: PGP signature
[PATCH 4/4] ARM: dts: at91: sam9x60_curiosity: fix eeprom compatible
The EEPROM memory on this board is microchip 24aa025e48 which is compatible with
at24c02 with a page size of 16. Fix the compatible accordingly.
Fixes: a79714f268 ("ARM: dts: Add device tree files for sam9x60_curiosity")
Signed-off-by: Durai Manickam KR
---
arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index 0d09679bd3..b06e0d9046 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -31,7 +31,7 @@
status = "okay";
eeprom@53 {
- compatible = "atmel,24c32";
+ compatible = "atmel,24c02";
reg = <0x53>;
pagesize = <16>;
};
--
2.25.1
[PATCH 3/4] ARM: dts: at91: sam9x60_curiosity: Enable NAND support
Enable the EBI and NAND flash controller. Define the pinctrl and
partition table.
Signed-off-by: Durai Manickam KR
---
arch/arm/dts/at91-sam9x60_curiosity.dts | 104
1 file changed, 104 insertions(+)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index d6ae3d648d..0d09679bd3 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -39,6 +39,44 @@
};
pinctrl {
+ ebi {
+ pinctrl_ebi_data_0_7: ebi-data-lsb-0 {
+ atmel,pins =
+ ;
+ };
+
+ pinctrl_ebi_addr_nand: ebi-addr-0 {
+ atmel,pins =
+ ;
+ };
+ };
+
+ nand {
+ pinctrl_nand_oe_we: nand-oe-we-0 {
+ atmel,pins =
+ ;
+ };
+
+ pinctrl_nand_rb: nand-rb-0 {
+ atmel,pins =
+ ;
+ };
+
+ pinctrl_nand_cs: nand-cs-0 {
+ atmel,pins =
+ ;
+ };
+ };
+
pinctrl_flx0: flx0_default {
atmel,pins =
;
+ status = "okay";
+
+ nand_controller: nand-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <_nand_oe_we _nand_cs
_nand_rb>;
+ status = "okay";
+
+ nand@3 {
+ reg = <0x3 0x0 0x80>;
+ atmel,rb = <0>;
+ rb-gpios = < 5 GPIO_ACTIVE_HIGH>;
+ cs-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x4>;
+ };
+
+ uboot@4 {
+ label = "u-boot";
+ reg = <0x4 0xc>;
+ };
+
+ ubootenvred@10 {
+ label = "U-Boot Env Redundant";
+ reg = <0x10 0x4>;
+ };
+
+ ubootenv@14 {
+ label = "U-Boot Env";
+ reg = <0x14 0x4>;
+ };
+
+ dtb@18 {
+ label = "device tree";
+ reg = <0x18 0x8>;
+ };
+
+ kernel@20 {
+ label = "kernel";
+ reg = <0x20 0x60>;
+ };
+
+ rootfs@80 {
+ label = "rootfs";
+ reg = <0x80 0x1f80>;
+ };
+ };
+ };
+ };
+};
+
{
phy-mode = "rmii";
status = "okay";
--
2.25.1
[PATCH 2/4] configs: at91: sam9x60_curiosity: Add sam9x60_curiosity_nandflash_defconfig
Add boot from NAND flash support for sam9x60_curiosity. Signed-off-by: Durai Manickam KR --- board/atmel/sam9x60_curiosity/MAINTAINERS | 1 + configs/sam9x60_curiosity_nandflash_defconfig | 92 +++ 2 files changed, 93 insertions(+) create mode 100644 configs/sam9x60_curiosity_nandflash_defconfig diff --git a/board/atmel/sam9x60_curiosity/MAINTAINERS b/board/atmel/sam9x60_curiosity/MAINTAINERS index 0d9369e027..992d3f4024 100644 --- a/board/atmel/sam9x60_curiosity/MAINTAINERS +++ b/board/atmel/sam9x60_curiosity/MAINTAINERS @@ -6,3 +6,4 @@ F: board/atmel/sam9x60_curiosity/ F: include/configs/sam9x60_curiosity.h F: configs/sam9x60_curiosity_mmc_defconfig F: configs/sam9x60_curiosity_mmc1_defconfig +F: configs/sam9x60_curiosity_nandflash_defconfig diff --git a/configs/sam9x60_curiosity_nandflash_defconfig b/configs/sam9x60_curiosity_nandflash_defconfig new file mode 100644 index 00..4146bf0ac9 --- /dev/null +++ b/configs/sam9x60_curiosity_nandflash_defconfig @@ -0,0 +1,92 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_ARCH_AT91=y +CONFIG_TEXT_BASE=0x23f0 +CONFIG_SYS_MALLOC_LEN=0x81000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONFIG_TARGET_SAM9X60_CURIOSITY=y +CONFIG_ATMEL_LEGACY=y +CONFIG_NR_DRAM_BANKS=8 +CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="at91-sam9x60_curiosity" +CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_DEBUG_UART_BASE=0xf200 +CONFIG_DEBUG_UART_CLOCK=2 +CONFIG_DEBUG_UART_BOARD_INIT=y +CONFIG_ENV_OFFSET_REDUND=0x10 +CONFIG_SYS_LOAD_ADDR=0x2200 +CONFIG_DEBUG_UART=y +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000bf00 +CONFIG_FIT=y +CONFIG_NAND_BOOT=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=12 root=ubi0:rootfs rw" +CONFIG_USE_BOOTCOMMAND=y +CONFIG_BOOTCOMMAND="nand read 0x2200 0x20 0x60; nand read 0x2100 0x18 0x2; bootz 0x2200 - 0x2100" +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_MISC_INIT_R=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_CBSIZE=256 +CONFIG_SYS_PBSIZE=281 +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_CLK=y +CONFIG_CMD_DM=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_NAND=y +CONFIG_CMD_NAND_TRIMFFS=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_BOOTP_BOOTFILESIZE=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_HASH=y +CONFIG_HASH_VERIFY=y +CONFIG_CMD_FAT=y +CONFIG_CMD_UBI=y +CONFIG_OF_CONTROL=y +CONFIG_ENV_IS_IN_NAND=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y +CONFIG_CLK=y +CONFIG_CLK_CCF=y +CONFIG_CLK_AT91=y +CONFIG_AT91_GENERIC_CLK=y +CONFIG_AT91_SAM9X60_PLL=y +CONFIG_CPU=y +CONFIG_AT91_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_AT91=y +CONFIG_ATMEL_EBI=y +CONFIG_MFD_ATMEL_SMC=y +CONFIG_I2C_EEPROM=y +CONFIG_MICROCHIP_FLEXCOM=y +CONFIG_GENERIC_ATMEL_MCI=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +# CONFIG_SYS_NAND_USE_FLASH_BBT is not set +CONFIG_DM_NAND_ATMEL=y +CONFIG_SYS_NAND_ONFI_DETECTION=y +CONFIG_PHY_MICREL=y +CONFIG_MACB=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_AT91=y +CONFIG_DM_SERIAL=y +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_ATMEL_USART=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_AT91=y +CONFIG_TIMER=y +CONFIG_MCHP_PIT64B_TIMER=y +CONFIG_W1=y +CONFIG_W1_GPIO=y +CONFIG_W1_EEPROM=y +CONFIG_W1_EEPROM_DS24XXX=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.25.1
[PATCH 1/4] configs: at91: sam9x60_curiosity: update sam9x60_curiosity_mmc_defconfig
- Enable Device model supported NAND driver configs in SDMMC defconfig. - Enable SYSRESET for Atmel/Microchip's platforms. Signed-off-by: Durai Manickam KR --- configs/sam9x60_curiosity_mmc_defconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/configs/sam9x60_curiosity_mmc_defconfig b/configs/sam9x60_curiosity_mmc_defconfig index 10937d67d7..279c4c1f4b 100644 --- a/configs/sam9x60_curiosity_mmc_defconfig +++ b/configs/sam9x60_curiosity_mmc_defconfig @@ -38,6 +38,8 @@ CONFIG_CMD_DM=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_NAND=y +CONFIG_CMD_NAND_TRIMFFS=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y @@ -50,6 +52,9 @@ CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_FAT=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_DM=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y CONFIG_CLK=y CONFIG_CLK_CCF=y CONFIG_CLK_AT91=y @@ -60,10 +65,17 @@ CONFIG_CPU=y CONFIG_AT91_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_AT91=y +CONFIG_ATMEL_EBI=y +CONFIG_MFD_ATMEL_SMC=y CONFIG_I2C_EEPROM=y CONFIG_MICROCHIP_FLEXCOM=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ATMEL=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_DM_NAND_ATMEL=y +CONFIG_SYS_NAND_ONFI_DETECTION=y CONFIG_PHY_MICREL=y CONFIG_MACB=y CONFIG_PINCTRL=y @@ -71,6 +83,8 @@ CONFIG_PINCTRL_AT91=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_ATMEL_USART=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_AT91=y CONFIG_TIMER=y CONFIG_MCHP_PIT64B_TIMER=y CONFIG_W1=y -- 2.25.1
[PATCH 0/4] Add support for sam9x60 curiosity
This patch series adds boot from NAND support, configs update and fixes. The changes has been done on top of u-boot version 2023.07. Durai Manickam KR (4): configs: at91: sam9x60_curiosity: update sam9x60_curiosity_mmc_defconfig configs: at91: sam9x60_curiosity: Add sam9x60_curiosity_nandflash_defconfig ARM: dts: at91: sam9x60_curiosity: Enable NAND support ARM: dts: at91: sam9x60_curiosity: fix eeprom compatible arch/arm/dts/at91-sam9x60_curiosity.dts | 106 +- board/atmel/sam9x60_curiosity/MAINTAINERS | 1 + configs/sam9x60_curiosity_mmc_defconfig | 14 +++ configs/sam9x60_curiosity_nandflash_defconfig | 92 +++ 4 files changed, 212 insertions(+), 1 deletion(-) create mode 100644 configs/sam9x60_curiosity_nandflash_defconfig -- 2.25.1
[PATCH] clk: ti: clk-sci: Notify AVS driver based upon clock rate
AVS driver needs to be notified before or after clock change,
depending upon new rate is greater or less than current clock rate.
Fixes: 1e0aa873bc7cd ("clk: clk-ti-sci: Notify AVS driver upon setting clock
rate")
Cc: Keerthy
Signed-off-by: Udit Kumar
---
Boot logs
https://gist.github.com/uditkumarti/5a05f9b18b8e5bc347ef98c901cc13d4
Separate patch for clk-sci driver to handle AVS,
as per review feedback in
https://lore.kernel.org/all/20230920120256.2901860-1-u-kum...@ti.com/
drivers/clk/ti/clk-sci.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/ti/clk-sci.c b/drivers/clk/ti/clk-sci.c
index 74df5a397b..8fc3254c99 100644
--- a/drivers/clk/ti/clk-sci.c
+++ b/drivers/clk/ti/clk-sci.c
@@ -91,12 +91,12 @@ static ulong ti_sci_clk_set_rate(struct clk *clk, ulong
rate)
const struct ti_sci_handle *sci = data->sci;
const struct ti_sci_clk_ops *cops = >ops.clk_ops;
int ret;
+ int freq_scale_up = rate >= ti_sci_clk_get_rate(clk) ? 1 : 0;
debug("%s(clk=%p, rate=%lu)\n", __func__, clk, rate);
-#ifdef CONFIG_K3_AVS0
- k3_avs_notify_freq(clk->id, clk->data, rate);
-#endif
+ if (IS_ENABLED(CONFIG_K3_AVS0) && freq_scale_up)
+ k3_avs_notify_freq(clk->id, clk->data, rate);
ret = cops->set_freq(sci, clk->id, clk->data, 0, rate, ULONG_MAX);
if (ret) {
@@ -104,6 +104,9 @@ static ulong ti_sci_clk_set_rate(struct clk *clk, ulong
rate)
return ret;
}
+ if (IS_ENABLED(CONFIG_K3_AVS0) && !freq_scale_up)
+ k3_avs_notify_freq(clk->id, clk->data, rate);
+
return rate;
}
--
2.34.1
Re: [PATCH v2] env: ti: ti_common.env: Fix get_overlaystring for FIT Image
On 9/21/23 5:49 AM, Manorit Chawdhry wrote:
After the refactor with conf- nodes in fitImage, overlaystring wasn't
didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
to handle conf- nodes.
Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get FIT config
string")
Reported-by: Aniket Limaye
Signed-off-by: Manorit Chawdhry
---
Test Logs:
=> setenv name_overlays ti/k3-dt.dtbo ti/k3-dt1.dtbo
=> run get_overlaystring
=> printenv overlaystring
overlaystring=#conf-ti_k3-dt.dtbo#conf-ti_k3-dt1.dtbo
---
Changes in v2:
- Fix tabs
- Link to v1:
https://lore.kernel.org/r/20230919-b4-upstream-overlaystring-v1-1-4c56e8d66...@ti.com
---
include/env/ti/ti_common.env | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
index e87a41a6590b..bc554fe7ca6d 100644
--- a/include/env/ti/ti_common.env
+++ b/include/env/ti/ti_common.env
@@ -16,9 +16,14 @@ addr_fit=0x9000
name_fit=fitImage
update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
get_overlaystring=
- for overlay in $name_overlays;
- do;
- setenv overlaystring ${overlaystring}'#'${overlay};
+ for overlay in $name_overlays; do;
+ if test ${boot_fit} -eq 1;
+ then
Why is the `then` tabbed out here, you can make it on the end of
the above line, same as you changed for `do`. Then untab all this
by one.
+ setexpr name_fit_overlay gsub / _
conf-${overlay};
+ setenv overlaystring
${overlaystring}'#'${name_fit_overlay};
+ else
+ setenv overlaystring
${overlaystring}'#'${overlay};
If you set `overlay` using setexpr, then this line is common and doesn't need to
be out here. Also do we use this overlaystring for anything other than the
FIT case? And if not, why do we need this boot_fit == 1 check at all?
Andrew
+ fi;
done;
get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
run_fit=run get_fit_config; bootm
${addr_fit}#${name_fit_config}${overlaystring}
---
base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
change-id: 20230915-b4-upstream-overlaystring-207e28b8c5fb
Best regards,
[PATCH v4] clk: ti: clk-k3: Notify AVS driver upon setting clock rate
AVS is enabled at R5 SPL stage, on few platforms like J721E and J7200 clk-k3 is used instead if clk-sci driver. Add support in clk-k3 driver as well to notify AVS driver on setting clock rate so that voltage is changed accordingly. Cc: Keerthy Signed-off-by: Udit Kumar --- Boot logs with v4: https://gist.github.com/uditkumarti/bab0ec09eadb4b167ec1ab93e08637a8 Change log: Change in v4: - changed if condition order as per review feedback - splitted patch into two - v3 link https://lore.kernel.org/all/20230920120256.2901860-1-u-kum...@ti.com/ Change in v3: - Updated AVS notification before/after clock setting based upon new and current rate - Added modifed notification in clk-sci driver as well - v2 link https://lore.kernel.org/all/20230919140408.2608521-1-u-kum...@ti.com/ Changes in v2: - Kept clk-sci.c as is because this is used by AM64 and AM65 platforms - v1 link https://lore.kernel.org/all/20230919060649.2518147-1-u-kum...@ti.com drivers/clk/ti/clk-k3.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c index ba925fa3c4..10f7240f77 100644 --- a/drivers/clk/ti/clk-k3.c +++ b/drivers/clk/ti/clk-k3.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "k3-clk.h" #define PLL_MIN_FREQ 8 @@ -242,7 +243,11 @@ static ulong ti_clk_set_rate(struct clk *clk, ulong rate) const struct clk_ops *ops; ulong new_rate, rem; ulong diff, new_diff; + int freq_scale_up = rate >= ti_clk_get_rate(clk) ? 1 : 0; + if (IS_ENABLED(CONFIG_K3_AVS0) && freq_scale_up) + k3_avs_notify_freq(data->map[clk->id].dev_id, + data->map[clk->id].clk_id, rate); /* * We must propagate rate change to parent if current clock type * does not allow setting it. @@ -339,6 +344,10 @@ static ulong ti_clk_set_rate(struct clk *clk, ulong rate) } } + if (IS_ENABLED(CONFIG_K3_AVS0) && !freq_scale_up) + k3_avs_notify_freq(data->map[clk->id].dev_id, + data->map[clk->id].clk_id, rate); + return new_rate; } -- 2.34.1
Re: [PATCH v6 1/2] schemas: Add some common reserved-memory usages
Hi Rob, On Thu, 21 Sept 2023 at 09:20, Rob Herring wrote: > > On Thu, Sep 21, 2023 at 9:38 AM Simon Glass wrote: > > > > Hi Rob, > > > > On Thu, 21 Sept 2023 at 08:25, Rob Herring wrote: > > > > > > On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote: > > > > > > > > It is common to split firmware into 'Platform Init', which does the > > > > initial hardware setup and a "Payload" which selects the OS to be > > > > booted. > > > > Thus an handover interface is required between these two pieces. > > > > > > > > This aims to provide an small schema addition for the memory mapping > > > > needed to keep these two pieces working together well. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > Changes in v6: > > > > - Drop mention of UEFI > > > > - Use compatible strings instead of node names > > > > > > > > Changes in v5: > > > > - Drop the memory-map node (should have done that in v4) > > > > - Tidy up schema a bit > > > > > > > > Changes in v4: > > > > - Make use of the reserved-memory node instead of creating a new one > > > > > > > > Changes in v3: > > > > - Reword commit message again > > > > - cc a lot more people, from the FFI patch > > > > - Split out the attributes into the /memory nodes > > > > > > > > Changes in v2: > > > > - Reword commit message > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++ > > > > 1 file changed, 71 insertions(+) > > > > create mode 100644 > > > > dtschema/schemas/reserved-memory/common-reserved.yaml > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > > new file mode 100644 > > > > index 000..4889f59 > > > > --- /dev/null > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > > @@ -0,0 +1,71 @@ > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > > +%YAML 1.2 > > > > +--- > > > > +$id: > > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Common memory reservations > > > > + > > > > +description: | > > > > + Specifies that the reserved memory region can be used for the purpose > > > > + indicated by its compatible string. > > > > + > > > > + Clients may reuse this reserved memory if they understand what it is > > > > for, > > > > + subject to the notes below. > > > > + > > > > +maintainers: > > > > + - Simon Glass > > > > + > > > > +allOf: > > > > + - $ref: reserved-memory.yaml > > > > + > > > > +properties: > > > > + compatible: > > > > +description: | > > > > + This describes some common memory reservations: > > > > + > > > > + acpi-reclaim: Contains ACPI tables; memory may be reclaimed > > > > when the > > > > + tables are no-longer needed > > > > > > I think you are mixing 2 things with the name here. What the memory > > > contains and what to do with it. You don't need the latter. The > > > consumer of the region will know what to do with it if anything based > > > on knowing what is in the region. For example, The DTB passed to the > > > OS is typically in a reserved region (probably still /mem-reserve/ > > > though). The DTB may remain there forever or the OS could copy it > > > somewhere else and free the reserved region. The Linux kernel does > > > both depending on the arch. (Of course there is no "dtb" compatible > > > because we have to pass the location of the dtb to even find the > > > reserved regions in the first place.) > > > > > > So the question here is whether just "acpi" (or "acpi-tables"?) would > > > be explicit enough? > > > > Yes acpi-tables would be enough. > > > > > > > > > + acpi-nvs: Contains ACPI Non-volatile-storage data; memory may > > > > be > > > > + reclaimed when the tables are no-longer needed > > > > > > No need to say anything about reclaiming. > > > > OK...so what about all that discussion about being able to reclaim the > > memory if you know what it is for? Where should that be written? Or is > > it somewhere else already? > > Reclaiming is a policy of the consumer of the data. It belongs in the > documentation of the consumer if you are going to document it. > > The global policy is you can't use reserved regions and you can't > reclaim them if you don't know what they are. If you want to add > something to that effect in reserved-memory.yaml or the spec, that's > fine, but that's not a per compatible thing. OK I will do that. > > > > I know some ACPIisms (e.g. DSDT), but I don't know what NVS or > > > "Non-volatile-storage data" is in an ACPI context. > > > > > > > + boot-code: Contains code used for booting; memory may be > > > > reclaimed by > > > > + the OS when it is running > > > > + boot-code: Contains data used for booting; memory may be > > > > reclaimed by > > > > > > boot-data? > > > > Yes > > > > > > > > > + the
Re: [SPAM] [PATCH] clk: fix count parameter type for clk_release_all
El Mon, Jun 19, 2023 at 01:47:52PM +0300, Eugen Hristev deia:
> The second parameter for clk_release_all is used as an unsigned
> (which makes sense) but the function prototype declares it as an int.
> This causes warnings/error like such below:
>
> include/clk.h:422:48: error: conversion to ‘int’ from ‘unsigned int’ may
> change the sign of the result [-Werror=sign-conversion]
> 422 | return clk_release_all(bulk->clks, bulk->count);
>
> To fix this, changed the type of the count to `unsigned int`
>
> Fixes: 82a8a669b4f7 ("clk: add clk_release_all()")
> Signed-off-by: Eugen Hristev
Reviewed-by: Xavier Drudis Ferran
> ---
> drivers/clk/clk-uclass.c | 7 ---
> include/clk.h| 4 ++--
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index dc3e9d6a2615..eada3a3a5b62 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -416,12 +416,13 @@ int clk_get_by_name_nodev(ofnode node, const char
> *name, struct clk *clk)
> return clk_get_by_index_nodev(node, index, clk);
> }
>
> -int clk_release_all(struct clk *clk, int count)
> +int clk_release_all(struct clk *clk, unsigned int count)
> {
> - int i, ret;
> + unsigned int i;
> + int ret;
>
This could also be changed in clk_enable_blk() and clk_disable_blk().
It's unlikely that we get so many clocks for it to matter, but it's
till wrong to compare int i to unsigned int bulk->count. That'd be a
different patch, though.
> for (i = 0; i < count; i++) {
> - debug("%s(clk[%d]=%p)\n", __func__, i, [i]);
> + debug("%s(clk[%u]=%p)\n", __func__, i, [i]);
>
> /* check if clock has been previously requested */
> if (!clk[i].dev)
> diff --git a/include/clk.h b/include/clk.h
> index d91285235f79..a342297007b6 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -243,7 +243,7 @@ static inline struct clk *devm_clk_get_optional(struct
> udevice *dev,
> *
> * Return: zero on success, or -ve error code.
> */
> -int clk_release_all(struct clk *clk, int count);
> +int clk_release_all(struct clk *clk, unsigned int count);
>
> /**
> * devm_clk_put - "free" a managed clock source
> @@ -307,7 +307,7 @@ clk_get_by_name_nodev(ofnode node, const char *name,
> struct clk *clk)
> return -ENOSYS;
> }
>
> -static inline int clk_release_all(struct clk *clk, int count)
> +static inline int clk_release_all(struct clk *clk, unsigned int count)
> {
> return -ENOSYS;
> }
> --
> 2.34.1
>
Re: [PATCHv8 00/15] net/lwip: add lwip library for the network stack
Hi, On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov wrote: > > > > On Wed, 13 Sept 2023 at 19:14, Tom Rini wrote: >> >> On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote: >> > > >> Then if for development you need to pull he history of lwip, you can >> > > >> do it with: >> > > >> git pull -s subtree lwip master --allow-unrelated-histories >> > > >> (but I think nobody will need this.) >> > > >> >> > > >> New update of the lwip net/lwip/lwip-external dir will be done with: >> > > >> git pull -s subtree lwip master --allow-unrelated-histories --squash >> > > >> Squash commit also has to be git format-patch friendly. >> > > >> >> > > >> If you are ok with that proposal I will send v9 with the first patch >> > > >> created with steps above. >> > > > >> > > > We've gone through this before. The whole purpose of this is not >> > > > having to maintain patches. >> > > > Simon, instead of "I had problems in the past", can you elaborate a >> > > > bit more? >> > > > >> > > > Tom said he is fine with subtrees instead of submodules and I know for >> > > > a fact EDK2 doesn't have too many issues with submodules. >> > > > Their documentation is pretty clear on building and requires >> > > > >> > > > git clone https://github.com/tianocore/edk2.git >> > > > cd edk2 >> > > > git submodule update --init >> > > > >> > > > Perhaps the situation has improved since you had issues? Nope. >> > > >> > > While I don't really care how you solve this technically, I'd *strongly* >> > > be interested for U-Boot to use *unmodified* lwIP sources where an >> > > explicit reference to an lwIP commit is used. I'd rather integrate >> > > bugfixes for U-Boot into lwIP than having the sources drift apart. >> > >> > Strongly agree here, we want to use upstream and all the combined >> > development and reviews etc rather than forking off and ending up with >> > yet another slightly different IP stack. The whole advantage of >> > adopting LWIP is the advantage of combined security, features and bugs >> > from a wide range of projects :-) >> >> Yes, this is what I want as well, and why I'm perhaps more agreeable >> with the approaches where it's a lot harder for us to start forking >> things unintentionally. I gather submodule rather than subtree would be >> better for that case? >> >> -- >> Tom > > > Yes, submodule will be a much better solution for us. And I also don't think > that today > there are any issues with submodules. It works well of OE, RPM and DEB builds, > distributions should not have problems with it. My particular experience is with coreboot. Some problems I have: 1. Updating the modules doesn't work and I need to reset, try the --init thing, fetch things manually, etc. etc. 2. In ChromiumOS coreboot we can't use submodules internally since each package has its own build script. E.g. we need to build coreboot separately from its blobs, fsp, external libraries, etc. At least there we can do this, but if U-Boot adopts a submodule for a core feature, this is going to create no end of problems. 3. It makes it impossible to patch lwip for any fix we need for a release 4. We still have to 'fast forward' to a new commit every now and then, which really is no easier than doing a merge commit for the changes since the last sync, is it? Really, we need a maintainer for the lwip piece, if we are to adopt it. Using submodules is not a substitute for that. Regards, Simon
Re: [PATCH 1/2] common: add prototype for populate_serial_number()
Hi Artur, On Thu, 21 Sept 2023 at 09:44, Artur Rojek wrote: > > Provide function prototype for populate_serial_number(). > This is useful for boards that wish to read their serial number from > EEPROM at init. > > Signed-off-by: Artur Rojek > --- > include/init.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/init.h b/include/init.h > index 3bf30476a2e0..e0b7fbc943ad 100644 > --- a/include/init.h > +++ b/include/init.h > @@ -283,6 +283,7 @@ void board_init_r(struct global_data *id, ulong dest_addr) > int cpu_init_r(void); > int last_stage_init(void); > int mac_read_from_eeprom(void); > +int populate_serial_number(int devnum); Please can you add a comment for this function? You can move it from the C file. I also suggest renaming it to something like eeprom_get_serial() or something like that. > int set_cpu_clk_info(void); > int update_flash_size(int flash_size); > int arch_early_init_r(void); > -- > 2.42.0 > BTW tlv_eeprom.c should really be converted to driver model. Regards, Simon
Re: Question about boot failure of AM64-SK
On Fri, Sep 22, 2023 at 12:03 AM Masahiro Yamada wrote: > > Hi. > > I am seeing a boot failure on AM64-SK. > > > I got the following error in SPL of the main core. > Do you have any clue? As a side-topic, I downloaded a prebuilt image from https://www.ti.com/tool/SK-AM64 It failed too (but in a different way). I flashed tisdk-debian-bookworm-am64xx-evm.wic to a SD card by using the 'dd' command, then I got this: U-Boot SPL 2023.04 (Jul 14 2023 - 08:10:06 +) EEPROM not available at 0x50, trying to read at 0x51 k3_system_controller sysctrler: k3_sysctrler_start: Boot Notification response failed. ret = -110 Firmware init failed on rproc (-110) resetting ... ti_sci system-controller@44043000: ti_sci_get_response: Message receive failed. ret = -110 ti_sci system-controller@44043000: ti_sci_get_response: Message receive failed. ret = -110 ti_sci system-controller@44043000: ti_sci_get_response: Message receive failed. ret = -110 no sysreset ### ERROR ### Please RESET the board ### Am I doing something wrong? -- Best Regards Masahiro Yamada
Re: [PATCH] bmips: Add Inteno XG6846 board
On Thu, Sep 21, 2023 at 04:00:24PM +0200, Daniel Schwierzeck wrote: > > > On 9/20/23 20:55, Tom Rini wrote: > > On Wed, Sep 20, 2023 at 08:51:07PM +0200, Linus Walleij wrote: > > > On Wed, Sep 20, 2023 at 4:22 PM Tom Rini wrote: > > > > > > > > + * This is a diet version of the device tree from Linux, > > > > > + * suitable for U-Boot. > > > > > + */ > > > > > > > > We shouldn't need a diet version of the tree. If it's reasonably done > > > > and stable in the kernel, we can even move towards just passing the > > > > U-Boot tree along to Linux. > > > > > > The device tree is not stable in the kernel. > > > It exists in OpenWrt and the creators of the bmips target are > > > kind of absent for the moment. The reason it is not in Linux > > > is that the "switch ethernet" driver and bindings need to be > > > upstreamed before the device trees can be upstreamed. > > > > > > But I can try to bring in more of it for sure :) > > > > Just like ARM the goal is just to drop in the kernel dts here. > > I guess this approach works well for ARM but not for MIPS. Most MIPS consumer > boards > are just maintained in OpenWRT but not in mainline Linux. And there are a few > boards > which have been just mainlined in U-Boot but not Linux so them also don't > have a > stable Linux DT. > > As MIPS is a dead architecture I suggest to just go with the minimal DT > suited for U-Boot ;) OK, I'll let it go then. > > > > > +++ b/board/inteno/xg6846/xg6846.c > > > > > @@ -0,0 +1,6 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > > +/* > > > > > + * Copyright (C) 2023 Linus Walleij > > > > > + */ > > > > > + > > > > > +#include > > > > > > > > So basically just an empty object file. Can we just _not_ have > > > > something here, if we perhaps don't set SYS_BOARD? I assume if there's > > > > just nothing here the link rules fail. > > > > > > Admittedly my knowledge of U-Boot internals are not the > > > best and this is a bit of a copy and paste job from > > > board/comtrend/ar5387un/ar-5387un.c which looks like > > > this and sets a bad example I suppose. > > > > Yeah, I didn't know we had someone doing that already here, whoops. > > > > > I guess you are asking me to modify U-Boots build system to > > > make the whole .c and Makefile inside a board subdir optional > > > so we can delete all such empty boardfiles? > > > > Well, it'd sure be nice if we could avoid having a dummy C file. If > > it looks like a nightmare once you take a peek, we can just live with > > it. > > > > I just tested it, you can simply add an empty board/inteno/xg6846/Makefile and > remove board/inteno/xg6846/xg6846.c. But you can also remove the Makefile. > Just the Kconfig and MAINTAINERS file are needed. Oh nice, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/2] board: Add support for Conclusive KSTR-SAMA5D27
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama
Signed-off-by: Jakub Klama
Co-developed-by: Marcin Jabrzyk
Signed-off-by: Marcin Jabrzyk
Signed-off-by: Artur Rojek
---
arch/arm/dts/Makefile | 3 +
arch/arm/dts/at91-kstr-sama5d27.dts | 310 ++
arch/arm/mach-at91/Kconfig| 13 +
board/conclusive/kstr-sama5d27/Kconfig| 15 +
board/conclusive/kstr-sama5d27/MAINTAINERS| 8 +
board/conclusive/kstr-sama5d27/Makefile | 5 +
.../conclusive/kstr-sama5d27/kstr-sama5d27.c | 235 +
configs/kstr_sama5d27_defconfig | 79 +
include/configs/kstr-sama5d27.h | 15 +
9 files changed, 683 insertions(+)
create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts
create mode 100644 board/conclusive/kstr-sama5d27/Kconfig
create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS
create mode 100644 board/conclusive/kstr-sama5d27/Makefile
create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c
create mode 100644 configs/kstr_sama5d27_defconfig
create mode 100644 include/configs/kstr-sama5d27.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157b1..8e4d33c01912 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1198,6 +1198,9 @@ dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
at91-sama5d27_wlsom1_ek.dtb
+dtb-$(CONFIG_TARGET_KSTR_SAMA5D27) += \
+ at91-kstr-sama5d27.dtb
+
dtb-$(CONFIG_TARGET_SAMA5D2_ICP) += \
at91-sama5d2_icp.dtb
diff --git a/arch/arm/dts/at91-kstr-sama5d27.dts
b/arch/arm/dts/at91-kstr-sama5d27.dts
new file mode 100644
index ..6de918a3c964
--- /dev/null
+++ b/arch/arm/dts/at91-kstr-sama5d27.dts
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * at91-kstr-sama5d27.dts - Device Tree file for Conclusive KSTR-SAMA5D27 board
+ *
+ * Copyright (C) 2019-2023 Conclusive Engineering Sp. z o. o.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include
+#include
+
+/ {
+ model = "Conclusive KSTR-SAMA5D27";
+ compatible = "conclusive,kstr-sama5d27", "atmel,sama5d2", "atmel,sama5";
+
+ chosen {
+ bootph-all;
+ stdout-path =
+ };
+
+ clocks {
+ main_xtal: main_xtal {
+ clock-frequency = <1200>;
+ };
+ };
+
+ ahb {
+ usb0: gadget@0030 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,sama5d3-udc";
+ reg = <0x0030 0x10
+ 0xfc02c000 0x400>;
+ interrupts = <42 IRQ_TYPE_LEVEL_HIGH 2>;
+ clocks = <_clk>, <>;
+ clock-names = "pclk", "hclk";
+ status =
[PATCH 1/2] common: add prototype for populate_serial_number()
Provide function prototype for populate_serial_number(). This is useful for boards that wish to read their serial number from EEPROM at init. Signed-off-by: Artur Rojek --- include/init.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/init.h b/include/init.h index 3bf30476a2e0..e0b7fbc943ad 100644 --- a/include/init.h +++ b/include/init.h @@ -283,6 +283,7 @@ void board_init_r(struct global_data *id, ulong dest_addr) int cpu_init_r(void); int last_stage_init(void); int mac_read_from_eeprom(void); +int populate_serial_number(int devnum); int set_cpu_clk_info(void); int update_flash_size(int flash_size); int arch_early_init_r(void); -- 2.42.0
[PATCH 0/2] Conclusive KSTR-SAMA5D27 support
Hi all, this series adds support for Conclusive KSTR-SAMA5D27, a Microchip SAMA5D27 SoC based Single Board Computer by Conclusive Engineering. Patch [1/2] adds a missing prototype for populate_serial_number(), which is used by KSTR-SAMA5D27 in order to read its serial number embedded in EEPROM TLV. Patch [2/2] introduces KSTR-SAMA5D27 support, including board init, Device Tree and defconfig files. An appropriate MAINTAINERS entry is also provided. A new board/conclusive subdirectory is added in anticipation of future support of our other products. Note that the "if (IS_ENABLED(CONFIG...))" checkpatch warnings for this patch are considered by me as false positives. Artur Rojek (2): common: add prototype for populate_serial_number() board: Add support for Conclusive KSTR-SAMA5D27 arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-kstr-sama5d27.dts | 310 ++ arch/arm/mach-at91/Kconfig| 13 + board/conclusive/kstr-sama5d27/Kconfig| 15 + board/conclusive/kstr-sama5d27/MAINTAINERS| 8 + board/conclusive/kstr-sama5d27/Makefile | 5 + .../conclusive/kstr-sama5d27/kstr-sama5d27.c | 235 + configs/kstr_sama5d27_defconfig | 79 + include/configs/kstr-sama5d27.h | 15 + include/init.h| 1 + 10 files changed, 684 insertions(+) create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts create mode 100644 board/conclusive/kstr-sama5d27/Kconfig create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS create mode 100644 board/conclusive/kstr-sama5d27/Makefile create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c create mode 100644 configs/kstr_sama5d27_defconfig create mode 100644 include/configs/kstr-sama5d27.h -- 2.42.0
[PATCH] misc: i2c_eeprom: consider pagesize when writing to eeprom
Calculate the maximum length of the buffer when writing
accross the page boundary. If the buffer length exceeds
the page boundary, split it. Use this length instead of
comparing the length with the pagesize, because the write
start address can be somewhere in the middle of a page.
Signed-off-by: Alex Michel
---
drivers/misc/i2c_eeprom.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index bdd7e018cc..f345e34179 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -60,6 +60,17 @@ static int i2c_eeprom_std_read(struct udevice *dev, int
offset, u
int8_t *buf,
return dm_i2c_read(dev, offset, buf, size);
}
+static int i2c_eeprom_len(unsigned offset, unsigned len, unsigned pagesize)
+{
+ int page_offset = ((offset) & (pagesize - 1));
+ unsigned maxlen = pagesize - page_offset;
+
+ if (len > maxlen)
+ len = maxlen;
+
+ return len;
+}
+
static int i2c_eeprom_std_write(struct udevice *dev, int offset,
const uint8_t *buf, int size)
{
@@ -67,7 +78,7 @@ static int i2c_eeprom_std_write(struct udevice *dev, int
offset,
int ret;
while (size > 0) {
- int write_size = min_t(int, size, priv->pagesize);
+ int write_size = i2c_eeprom_len(offset, size, priv->pagesize);
ret = dm_i2c_write(dev, offset, buf, write_size);
if (ret)
--
2.34.1
Re: [PATCH v1 2/2] spl: Add support for booting from ESP
On Thu, Sep 21, 2023 at 05:03:37PM +0530, mchit...@ventanamicro.com wrote:
> On Thu, 2023-09-14 at 12:29 -0400, Tom Rini wrote:
> > On Thu, Sep 14, 2023 at 03:38:21PM +0530, Mayuresh Chitale wrote:
> >
> > > Some platforms as described by EBBR specification may store images
> > > in
> > > the FIRMWARE directory of the UEFI system partition(ESP). Add
> > > support
> > > to boot from the EFI system partition if it is enabled for a
> > > platform.
> > >
> > > Signed-off-by: Mayuresh Chitale
> > [snip]
> > > +config SPL_ESP_BOOT
> > > + bool "Load next stage boot image from the UEFI system
> > > partition"
> > > + select SPL_PARTITION_TYPE_GUID
> > > + help
> > > + When enabled, first try to boot from the UEFI system
> > > partition as
> > > + described in the Ch.4 of the EBBR specification.
> >
> > We need to select this by perhaps BOOT_DEFAULTS or BOOTMETH_DISTRO,
> > whatever is supposed to signify that yes, this is going to be a
> > SystemReady IR (or higher) compliant build.
> I am not sure about the SystemReady compliance but I think the config
> option can be enabled for those platforms which require it.
It's "nearly everyone" that needs the option, which is why I'm saying it
needs to be part of the high level options that a board selects to say
they want to be compliant.
> > [snip]
> > > int spl_blk_load_image(struct spl_image_info *spl_image,
> > > struct spl_boot_device *bootdev,
> > > enum uclass_id uclass_id, int devnum, int
> > > partnum)
> > > {
> > > const char *filename = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME;
> > > - struct legacy_img_hdr *header;
> > [snip]
> > > @@ -63,24 +88,26 @@ int spl_blk_load_image(struct spl_image_info
> > > *spl_image,
> > > }
> > >
> > > blk_show_device(uclass_id, devnum);
> > > - header = spl_get_load_buffer(-sizeof(*header),
> > > sizeof(*header));
> > > -
> > [snip]
> >
> > Is this an artifact of Sean's patch series where "header" is no
> > longer
> > actually used? As-is this won't compile on top of next (which is
> > where
> > given Sean's feedback, the series needs to be rebased upon anyhow).
> Yes, I will rebase on the latest next without Sean's series and resend
> the patch.
OK.
> > > + /*
> > > + * First try to boot from EFI System partition. In case of
> > > failure,
> > > + * fall back to the configured partition.
> > > + */
> >
> > I don't know that this is the right behavior. If we're configured to
> > boot from partition X, we boot from partition X. If we're configured
> > to
> > find the ESP and use that, we find and use that.
>
> This is to maintain compatibility and make more attempts to boot. So
> the same SPL binary can load images from devices with or without the
> ESP.
Yes, I don't think that's what we want. It should be an either/or not a
a then b.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCHv9 01/15] submodule: add lwIP as git submodule
On Wed, Sep 20, 2023 at 07:03:07PM -0600, Simon Glass wrote: > Hi Maxim, > > On Thu, 14 Sept 2023 at 10:20, Maxim Uvarov wrote: > > > > add external lwIP library as a git submodule. > > Oh dear...what is the motivation for using a submodule? That we don't have a better alternative. Using "git subtree" has it's own problems and won't make things overall better. > Our current stack is nicely integrated into U-Boot. This would make > moving between development branches much more painful. It really shouldn't matter in that case. Unless you're trying out a new lwip upstream commit, nothing changes in there. It _may_ mean that if we want to update lwip it's not something that can be staged first in the -next branch but instead something to pull in just after release, but I'd need to see how smart or not git is today about things like that. > I would much prefer that we bring in the necessary code, and that you > send a patch every 3 months or so to deal with updates, making sure > there are no code-size regressions. And I much prefer something that will make sure that we don't start making changes in upstream code and diverging. I don't think there's a mechanic short of submodule that will do that for us. -- Tom signature.asc Description: PGP signature
[Question] TI's u-boot.img is built twice
Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure -- Best Regards Masahiro Yamada
Re: [PATCH 09/32] spl: Avoid an #ifdef when printing gd->malloc_ptr
On Wed, Sep 20, 2023 at 07:03:34PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 30 Aug 2023 at 15:39, Tom Rini wrote:
> >
> > On Wed, Aug 30, 2023 at 12:04:40PM -0600, Simon Glass wrote:
> > > Use an accessor in the header file to avoid this.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > common/spl/spl.c | 9 +
> > > include/asm-generic/global_data.h | 7 +++
> > > 2 files changed, 12 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > > index f0a90c280da..f5cef81000c 100644
> > > --- a/common/spl/spl.c
> > > +++ b/common/spl/spl.c
> > > @@ -876,10 +876,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > } else {
> > > debug("Unsupported OS image.. Jumping nevertheless..\n");
> > > }
> > > -#if CONFIG_VAL(SYS_MALLOC_F_LEN) && !defined(CONFIG_SPL_SYS_MALLOC_SIZE)
> > > - debug("SPL malloc() used 0x%lx bytes (%ld KB)\n", gd->malloc_ptr,
> > > - gd->malloc_ptr / 1024);
> > > -#endif
> > > + if (IS_ENABLED(CONFIG_SYS_MALLOC_F) &&
> > > + !IS_ENABLED(CONFIG_SPL_SYS_MALLOC_SIZE))
> > > + debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > + gd_malloc_ptr(), gd_malloc_ptr() / 1024);
This is not more readable. But I guess my comment was unclear as you're
mixing changes here. gd_malloc_ptr() rather than gd->malloc_ptr is a
wash, to me. I think one could argue it's not a helpful abstraction.
but it's so that you can avoid CONFIG_VAL here, and say "if (...)" not
"#if ..." here.
> > > +
> > > bootstage_mark_name(get_bootstage_id(false), "end phase");
> > > #ifdef CONFIG_BOOTSTAGE_STASH
> > > ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> > > diff --git a/include/asm-generic/global_data.h
> > > b/include/asm-generic/global_data.h
> > > index 8fc205ded1a..edf9ff6823f 100644
> > > --- a/include/asm-generic/global_data.h
> > > +++ b/include/asm-generic/global_data.h
> > > @@ -573,6 +573,13 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
> > > #define gd_malloc_start()0
> > > #define gd_set_malloc_start(val)
> > > #endif
> > > +
> > > +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
> > > +#define gd_malloc_ptr() gd->malloc_ptr
> > > +#else
> > > +#define gd_malloc_ptr() 0L
> > > +#endif
> > > +
> > > /**
> > > * enum gd_flags - global data flags
> > > *
> >
> > This is another case where readability is not improved. I also have a
> > bad feeling that changing that exact area had some unintended
> > consequences from the compiler, that totally should not have happened.
> > But maybe that was something in a similar code section instead.
>
> The improvement is in the C file...here we have an accessor in the
> header file as has been done elsewhere.
>
> Do you have any more details on the problem you mention? I will align
> the accessor to the struct member which should resolve it.
It's unfortunately one of those cases to do a global before/after build
and see if anything does or does not get tripped up. As I believe I did
use CONFIG_VAL there and not a check on CONFIG_SYS_MALLOC_F itself for a
reason, at the time.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] common: Drop linux/printk.h from common header
On Wed, Sep 20, 2023 at 07:03:25PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 15 Sept 2023 at 15:54, Tom Rini wrote: > > > > On Fri, Sep 15, 2023 at 02:01:33PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 15 Sept 2023 at 13:48, Tom Rini wrote: > > > > > > > > On Thu, Sep 14, 2023 at 06:21:46PM -0600, Simon Glass wrote: > > > > > > > > > This old patch was marked as deferred. Bring it back to life, to > > > > > continue > > > > > towards the removal of common.h > > > > > > > > > > Move this out of the common header and include it only where needed. > > > > > > > > > > Signed-off-by: Simon Glass > > > > [snip] > > > > > 317 files changed, 322 insertions(+), 3 deletions(-) > > > > > > > > So, going back to the original series here, how did you determine that > > > > the files changed here need ? I can see how to get > > > > there with some grep'ing but I think my original complaint was that we > > > > added the new header too widely. > > > > > > Basically I used ctags to get the symbols from the header file, then > > > grepped files for them. For that one, it is: > > > > > > KERN_ALERT,KERN_CONT,KERN_CRIT,KERN_DEBUG,KERN_EMERG,KERN_ERR,KERN_INFO,KERN_NOTICE,KERN_WARNING,__KERNEL_PRINTK__,__printk,no_printk,pr_alert,pr_cont,pr_crit,pr_debug,pr_debug,pr_devel,pr_devel,pr_emerg,pr_err,pr_fmt,pr_info,pr_notice,pr_warn,pr_warning,printk,printk_once > > > > OK, good. > > > > > I was a little miffed that a comment along these lines from Heinrich, > > > with no actual evidence, and no response to my follow-up questions, > > > caused the series to be dropped. It isn't easy to do these sorts of > > > clean-ups. > > > > Well, I know earlier on I had concerns and spotted specific cases where > > it was off. > > > > > A lot of files include things like net.h and image.h which bring in > > > many headers...but we should clean up those header files up too > > > (particularly image.h). So I think the standard should be: "include > > > what you use". > > > > Yes, we should first get rid of common.h and then see what we can > > remove next. > > Are you OK with this patch? If so I could send another, but should > perhaps wait until this is in -next ? I'll pick this up for next soon, yes. And then we can do another. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 1/2] schemas: Add some common reserved-memory usages
On Thu, Sep 21, 2023 at 9:38 AM Simon Glass wrote: > > Hi Rob, > > On Thu, 21 Sept 2023 at 08:25, Rob Herring wrote: > > > > On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote: > > > > > > It is common to split firmware into 'Platform Init', which does the > > > initial hardware setup and a "Payload" which selects the OS to be booted. > > > Thus an handover interface is required between these two pieces. > > > > > > This aims to provide an small schema addition for the memory mapping > > > needed to keep these two pieces working together well. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > Changes in v6: > > > - Drop mention of UEFI > > > - Use compatible strings instead of node names > > > > > > Changes in v5: > > > - Drop the memory-map node (should have done that in v4) > > > - Tidy up schema a bit > > > > > > Changes in v4: > > > - Make use of the reserved-memory node instead of creating a new one > > > > > > Changes in v3: > > > - Reword commit message again > > > - cc a lot more people, from the FFI patch > > > - Split out the attributes into the /memory nodes > > > > > > Changes in v2: > > > - Reword commit message > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++ > > > 1 file changed, 71 insertions(+) > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > new file mode 100644 > > > index 000..4889f59 > > > --- /dev/null > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > @@ -0,0 +1,71 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Common memory reservations > > > + > > > +description: | > > > + Specifies that the reserved memory region can be used for the purpose > > > + indicated by its compatible string. > > > + > > > + Clients may reuse this reserved memory if they understand what it is > > > for, > > > + subject to the notes below. > > > + > > > +maintainers: > > > + - Simon Glass > > > + > > > +allOf: > > > + - $ref: reserved-memory.yaml > > > + > > > +properties: > > > + compatible: > > > +description: | > > > + This describes some common memory reservations: > > > + > > > + acpi-reclaim: Contains ACPI tables; memory may be reclaimed > > > when the > > > + tables are no-longer needed > > > > I think you are mixing 2 things with the name here. What the memory > > contains and what to do with it. You don't need the latter. The > > consumer of the region will know what to do with it if anything based > > on knowing what is in the region. For example, The DTB passed to the > > OS is typically in a reserved region (probably still /mem-reserve/ > > though). The DTB may remain there forever or the OS could copy it > > somewhere else and free the reserved region. The Linux kernel does > > both depending on the arch. (Of course there is no "dtb" compatible > > because we have to pass the location of the dtb to even find the > > reserved regions in the first place.) > > > > So the question here is whether just "acpi" (or "acpi-tables"?) would > > be explicit enough? > > Yes acpi-tables would be enough. > > > > > > + acpi-nvs: Contains ACPI Non-volatile-storage data; memory may be > > > + reclaimed when the tables are no-longer needed > > > > No need to say anything about reclaiming. > > OK...so what about all that discussion about being able to reclaim the > memory if you know what it is for? Where should that be written? Or is > it somewhere else already? Reclaiming is a policy of the consumer of the data. It belongs in the documentation of the consumer if you are going to document it. The global policy is you can't use reserved regions and you can't reclaim them if you don't know what they are. If you want to add something to that effect in reserved-memory.yaml or the spec, that's fine, but that's not a per compatible thing. > > I know some ACPIisms (e.g. DSDT), but I don't know what NVS or > > "Non-volatile-storage data" is in an ACPI context. > > > > > + boot-code: Contains code used for booting; memory may be > > > reclaimed by > > > + the OS when it is running > > > + boot-code: Contains data used for booting; memory may be > > > reclaimed by > > > > boot-data? > > Yes > > > > > > + the OS when it is running > > > > I thought these were for stages before we get to OS? > > Yes...but of course these will be passed on to the OS in some form. > See above re reclaiming. > > > > > > + runtime-code: Contains code used for interacting with the > > > system when > > > + running; memory may be reclaimed if this code is not called > > > +
Re: [PATCH] arm64: versal: Add SelectMAP boot mode identification
On 9/21/23 13:14, Michal Simek wrote:
On 9/19/23 14:47, Polak, Leszek wrote:
Add missing SelectMAP bootmode for proper identification during boot.
The SelectMAP configuration interface provides an 8-bit, 16-bit or
32-bit bidirectional data bus interface to the Versal FPGA
configuration logic that can be used for both configuration and
readback.
A connected microcontoller to the SelectMAP interface can load boot
image with bitstream, TF-A (ARM Trusted Firmware) and U-Boot.
This commit adds the missing identification of the SelectMAP mode.
Signed-off-by: Leszek Polak
Cc: Michal Simek
Cc: Stefan Roese
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/mach-versal-net/include/mach/hardware.h | 1 +
arch/arm/mach-versal/include/mach/hardware.h | 1 +
board/xilinx/versal-net/board.c | 4
board/xilinx/versal/board.c | 5 +
4 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 9bddb8b00723..767cdd368682 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -66,6 +66,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/arch/arm/mach-versal/include/mach/hardware.h
b/arch/arm/mach-versal/include/mach/hardware.h
index 000af974e867..9d1c2f0dcfc1 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -82,6 +82,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/board/xilinx/versal-net/board.c
b/board/xilinx/versal-net/board.c
index f0d2224b332e..992e0df73b30 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -287,6 +287,10 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ mode = "selectmap";
We are not defining distro boot for selectmap that's why boot_targets
don't need to be extended. That's why please remove this line.
+ break;
default:
mode = "";
printf("Invalid Boot Mode:0x%x\n", bootmode);
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 60bf37d3c90f..b619dbc73c80 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -213,6 +213,10 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ mode = "selectmap";
The same here.
+ break;
default:
mode = "";
printf("Invalid Boot Mode:0x%x\n", bootmode);
@@ -298,6 +302,7 @@ enum env_location env_get_location(enum
env_operation op, int prio)
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
case JTAG_MODE:
+ case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
--
2.42.0
The rest looks good to me.
Thanks,
Michal
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Question about boot failure of AM64-SK
Hi.
I am seeing a boot failure on AM64-SK.
I got the following error in SPL of the main core.
Do you have any clue?
Error reading cluster
fit read sector 0, sectors=985528, dst=, count=18446744073709551615,
size=0xf09b8
The resulting count looks crazy, but I imagine it was just
that the negative error code was converted to ulong.
For debugging, I enabled debug() under common/spl/.
The rest is the same as the latest mainline.
The full log is as follows:
U-Boot SPL 2023.10-rc4-00047-gb9b83a86f0-dirty (Sep 21 2023 - 14:38:15 +)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.7--v09.00.07 (Kool Koala)')
EEPROM not available at 0x50, trying to read at 0x51
SPL initial stack usage: 13384 bytes
SPL malloc() before relocation used 0x32ec bytes (12 KB)
>>SPL: board_init_r()
spl_init
Trying to boot from MMC2
spl: mmc boot mode: fs
Found FIT
fit read sector 0, sectors=874340, dst=, count=874339, size=0xd5764
firmware: 'atf'
Embedded data: dst=701c, size=b2a8
Warning: Detected image signing certificate on GP device. Skipping
certificate to prevent boot failure. This will fail if the image was
also encrypted
Image OS is ARM Trusted Firmware
loadables: 'tee'
Embedded data: dst=9e80, size=753e0
Warning: Detected image signing certificate on GP device. Skipping
certificate to prevent boot failure. This will fail if the image was
also encrypted
Loadable is Trusted Execution Environment
loadables: 'dm'
Embedded data: dst=8900, size=0
Loadable is Unknown OS
loadables: 'spl'
Embedded data: dst=8008, size=4ff18
Warning: Detected image signing certificate on GP device. Skipping
certificate to prevent boot failure. This will fail if the image was
also encrypted
Loadable is U-Boot
fdt: 'fdt-1'
Embedded data: dst=800cf888, size=2af2
Warning: Detected image signing certificate on GP device. Skipping
certificate to prevent boot failure. This will fail if the image was
also encrypted
loadables: 'spl'
no string for index 3
Unsupported OS image.. Jumping nevertheless..
Loading Environment from MMC... MMC Device 0 not found
*** Warning - No MMC card found, using default environment
Starting ATF on ARM64 core...
NOTICE: BL31: v2.9(release):v2.9.0
NOTICE: BL31: Built : 10:06:58, Sep 21 2023
I/TC:
I/TC: OP-TEE version: 3.22.0 (gcc version 11.4.0 (Ubuntu
11.4.0-1ubuntu1~22.04)) #1 Thu Sep 21 10:06:54 UTC 2023 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check
https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.7--v09.00.07 (Kool Koala)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Fixing SA2UL firewall owner for GP device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot
U-Boot SPL 2023.10-rc4-00047-gb9b83a86f0-dirty (Sep 21 2023 - 14:38:20 +)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.7--v09.00.07 (Kool Koala)')
SPL malloc() before relocation used 0x1f80 bytes (7 KB)
>>SPL: board_init_r()
spl_init
Trying to boot from MMC2
spl: mmc boot mode: fs
Found FIT
Error reading cluster
fit read sector 0, sectors=985528, dst=, count=18446744073709551615,
size=0xf09b8
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
My build sequence is something like this:
# for wakeup
make -j "$(nproc)" O=build-wakeup CROSS_COMPILE=arm-linux-gnueabihf- \
BINMAN_INDIRS="${SNAPCRAFT_STAGE}/ti-linux-firmware" \
am64x_evm_r5_defconfig all
cp build-wakeup/tiboot3-am64x-gp-evm.bin "${STAGE}/tiboot3.bin"
# for main
make -j "$(nproc)" O=build-main am64x_evm_a53_defconfig
make -j "$(nproc)" O=build-main CROSS_COMPILE=aarch64-linux-gnu- \
BINMAN_INDIRS="${STAGE}/ti-linux-firmware" \
BL31="${STAGE}/bl31.bin" \
TEE="${STAGE}/tee-raw.bin" \
all
cp build-main/tispl.bin build-main/u-boot.img "${STAGE}"
Strangely, AM62-SK booted successfully,
but AM64-SK failed.
I do not know why.
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 RESEND] mmc: dw_mmc: reset controller after data error
On 6/19/23 13:33, Eugen Hristev wrote:
From: Ziyuan Xu
Per dw_mmc databook, it's recommended to reset the host controller if
some data-related error occurred.
Implement a reset mechanism.
Signed-off-by: Ziyuan Xu
Co-developed-by: Jason Zhu
Signed-off-by: Jason Zhu
[eugen.hris...@collabora.com: modified a bit the variables initialization]
Signed-off-by: Eugen Hristev
---
Hi,
Gentle ping.
This patch require any more changes?
Thanks,
Eugen
drivers/mmc/dw_mmc.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 5085a3b491da..d6cad998b0cd 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -138,7 +138,7 @@ static int dwmci_data_transfer(struct dwmci_host *host,
struct mmc_data *data)
{
struct mmc *mmc = host->mmc;
int ret = 0;
- u32 timeout, mask, size, i, len = 0;
+ u32 timeout, reset_timeout = 100, status, ctrl, mask, size, i, len = 0;
u32 *buf = NULL;
ulong start = get_timer(0);
u32 fifo_depth = (((host->fifoth_val & RX_WMARK_MASK) >>
@@ -159,6 +159,24 @@ static int dwmci_data_transfer(struct dwmci_host *host,
struct mmc_data *data)
/* Error during data transfer. */
if (mask & (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
debug("%s: DATA ERROR!\n", __func__);
+
+ dwmci_wait_reset(host, DWMCI_RESET_ALL);
+ dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_PRV_DAT_WAIT |
+DWMCI_CMD_UPD_CLK | DWMCI_CMD_START);
+
+ do {
+ status = dwmci_readl(host, DWMCI_CMD);
+ if (!reset_timeout--)
+ break;
+ udelay(100);
+ } while (status & DWMCI_CMD_START);
+
+ if (!host->fifo_mode) {
+ ctrl = dwmci_readl(host, DWMCI_BMOD);
+ ctrl |= DWMCI_BMOD_IDMAC_RESET;
+ dwmci_writel(host, DWMCI_BMOD, ctrl);
+ }
+
ret = -EINVAL;
break;
}
Re: [PATCH] clk: fix count parameter type for clk_release_all
On 6/19/23 13:47, Eugen Hristev wrote:
The second parameter for clk_release_all is used as an unsigned
(which makes sense) but the function prototype declares it as an int.
This causes warnings/error like such below:
include/clk.h:422:48: error: conversion to ‘int’ from ‘unsigned int’ may change
the sign of the result [-Werror=sign-conversion]
422 | return clk_release_all(bulk->clks, bulk->count);
To fix this, changed the type of the count to `unsigned int`
Fixes: 82a8a669b4f7 ("clk: add clk_release_all()")
Signed-off-by: Eugen Hristev
---
drivers/clk/clk-uclass.c | 7 ---
include/clk.h| 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index dc3e9d6a2615..eada3a3a5b62 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -416,12 +416,13 @@ int clk_get_by_name_nodev(ofnode node, const char *name,
struct clk *clk)
return clk_get_by_index_nodev(node, index, clk);
}
-int clk_release_all(struct clk *clk, int count)
+int clk_release_all(struct clk *clk, unsigned int count)
{
- int i, ret;
+ unsigned int i;
+ int ret;
for (i = 0; i < count; i++) {
- debug("%s(clk[%d]=%p)\n", __func__, i, [i]);
+ debug("%s(clk[%u]=%p)\n", __func__, i, [i]);
/* check if clock has been previously requested */
if (!clk[i].dev)
diff --git a/include/clk.h b/include/clk.h
index d91285235f79..a342297007b6 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -243,7 +243,7 @@ static inline struct clk *devm_clk_get_optional(struct
udevice *dev,
*
* Return: zero on success, or -ve error code.
*/
-int clk_release_all(struct clk *clk, int count);
+int clk_release_all(struct clk *clk, unsigned int count);
/**
* devm_clk_put - "free" a managed clock source
@@ -307,7 +307,7 @@ clk_get_by_name_nodev(ofnode node, const char *name, struct
clk *clk)
return -ENOSYS;
}
-static inline int clk_release_all(struct clk *clk, int count)
+static inline int clk_release_all(struct clk *clk, unsigned int count)
{
return -ENOSYS;
}
Hi,
gentle ping.
Thanks,
Eugen
Re: [PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL
On 8/1/23 10:28, Eugen Hristev wrote: This series adds support for DFU in SPL for rockchip rk3588 on rock5b board. Namely, when SPL is loaded via rockusb (thus via USB), having the `same-as-spl` boot order item, after having detected that it was loaded from USB, it will lookup the gadget USB node in DT and boot via DFU. Some changes were required namely: - DFU needs environment, hence adding environment variables into DFU - added bootph-all to nodes such that they are available in SPL - insert gadget into boot order I had to port one patch for DWC3 from Linux, and include in this series the patches that are floating from Venkatesh that fixup the DWC3 (https://marc.info/?l=u-boot=168351919807081=2 ) I know that Marek NAKed them and I am fine with it, I am not trying to sneak in any patches, they are not to be merged, also this patch `usb: dwc3: Increase DWC3 controller halt timeout` is in the same bucket so Marek you can NAK this one as well, no problem, I am just sending out all the series so maybe the rockchip part for the gadget can be picked up and if people want to use the DFU SPL gadget can also manually pick the DWC3 patches. The branch with all the patches is available here : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot Thanks! Changes in v2: - rebased on latest upstream which caused a change in the config patch. Eugen Hristev (7): rockchip: allow env defines for SPL build usb: dwc3: Increase DWC3 controller halt timeout ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes ARM: mach-rockchip: spl-boot-order: add possibility to DFU ARM: mach-rockchip: rk3588: add gadget device to the boot order rockchip: rk3588: prepare env for DFU configs: rockchip: rock5b-rk3588: enable DFU and related configs Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 + arch/arm/mach-rockchip/rk3588/rk3588.c | 1 + arch/arm/mach-rockchip/spl-boot-order.c | 3 +++ configs/rock5b-rk3588_defconfig | 18 +++--- drivers/usb/dwc3/core.c | 32 +++-- drivers/usb/dwc3/gadget.c | 20 +++- drivers/usb/dwc3/gadget.h | 14 +++ include/configs/rk3588_common.h | 9 ++- include/configs/rockchip-common.h | 4 9 files changed, 76 insertions(+), 31 deletions(-) Hello Kever, I see in patchwork this series is marked as 'Changes requested'. Do you wish to tell me which are the changes you requested, as I did not see anything in your replies. I am interested to see the patches related to rockchip (not the DWC3), if it's fine for you to merge them. Thanks, Eugen
Re: [PATCH v6 1/2] schemas: Add some common reserved-memory usages
Hi Rob, On Thu, 21 Sept 2023 at 08:25, Rob Herring wrote: > > On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote: > > > > It is common to split firmware into 'Platform Init', which does the > > initial hardware setup and a "Payload" which selects the OS to be booted. > > Thus an handover interface is required between these two pieces. > > > > This aims to provide an small schema addition for the memory mapping > > needed to keep these two pieces working together well. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v6: > > - Drop mention of UEFI > > - Use compatible strings instead of node names > > > > Changes in v5: > > - Drop the memory-map node (should have done that in v4) > > - Tidy up schema a bit > > > > Changes in v4: > > - Make use of the reserved-memory node instead of creating a new one > > > > Changes in v3: > > - Reword commit message again > > - cc a lot more people, from the FFI patch > > - Split out the attributes into the /memory nodes > > > > Changes in v2: > > - Reword commit message > > > > .../reserved-memory/common-reserved.yaml | 71 +++ > > 1 file changed, 71 insertions(+) > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml > > b/dtschema/schemas/reserved-memory/common-reserved.yaml > > new file mode 100644 > > index 000..4889f59 > > --- /dev/null > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > > @@ -0,0 +1,71 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common memory reservations > > + > > +description: | > > + Specifies that the reserved memory region can be used for the purpose > > + indicated by its compatible string. > > + > > + Clients may reuse this reserved memory if they understand what it is for, > > + subject to the notes below. > > + > > +maintainers: > > + - Simon Glass > > + > > +allOf: > > + - $ref: reserved-memory.yaml > > + > > +properties: > > + compatible: > > +description: | > > + This describes some common memory reservations: > > + > > + acpi-reclaim: Contains ACPI tables; memory may be reclaimed when > > the > > + tables are no-longer needed > > I think you are mixing 2 things with the name here. What the memory > contains and what to do with it. You don't need the latter. The > consumer of the region will know what to do with it if anything based > on knowing what is in the region. For example, The DTB passed to the > OS is typically in a reserved region (probably still /mem-reserve/ > though). The DTB may remain there forever or the OS could copy it > somewhere else and free the reserved region. The Linux kernel does > both depending on the arch. (Of course there is no "dtb" compatible > because we have to pass the location of the dtb to even find the > reserved regions in the first place.) > > So the question here is whether just "acpi" (or "acpi-tables"?) would > be explicit enough? Yes acpi-tables would be enough. > > > + acpi-nvs: Contains ACPI Non-volatile-storage data; memory may be > > + reclaimed when the tables are no-longer needed > > No need to say anything about reclaiming. OK...so what about all that discussion about being able to reclaim the memory if you know what it is for? Where should that be written? Or is it somewhere else already? > > I know some ACPIisms (e.g. DSDT), but I don't know what NVS or > "Non-volatile-storage data" is in an ACPI context. > > > + boot-code: Contains code used for booting; memory may be > > reclaimed by > > + the OS when it is running > > + boot-code: Contains data used for booting; memory may be > > reclaimed by > > boot-data? Yes > > > + the OS when it is running > > I thought these were for stages before we get to OS? Yes...but of course these will be passed on to the OS in some form. See above re reclaiming. > > > + runtime-code: Contains code used for interacting with the system > > when > > + running; memory may be reclaimed if this code is not called > > + runtime-data: Contains data used for interacting with the system > > when > > + running; memory may be reclaimed if the runtime code is not used > > "boot" vs. "runtime" seem too vague. However, if these mean EFI boot > time services and runtime services, then I understand exactly what > they are. In that case dropping 'uefi,' was a mistake. But EFI has its > own way to define these regions, right? I really don't want to do another round of that circle. I was asked to drop mention of EFI which I did. If these are too vague, what should I do instead? Perhaps: boot-code / data os-code / data ? Regards, Simon
Re: [PATCH v6 1/2] schemas: Add some common reserved-memory usages
On Thu, Sep 7, 2023 at 4:40 PM Simon Glass wrote: > > It is common to split firmware into 'Platform Init', which does the > initial hardware setup and a "Payload" which selects the OS to be booted. > Thus an handover interface is required between these two pieces. > > This aims to provide an small schema addition for the memory mapping > needed to keep these two pieces working together well. > > Signed-off-by: Simon Glass > --- > > Changes in v6: > - Drop mention of UEFI > - Use compatible strings instead of node names > > Changes in v5: > - Drop the memory-map node (should have done that in v4) > - Tidy up schema a bit > > Changes in v4: > - Make use of the reserved-memory node instead of creating a new one > > Changes in v3: > - Reword commit message again > - cc a lot more people, from the FFI patch > - Split out the attributes into the /memory nodes > > Changes in v2: > - Reword commit message > > .../reserved-memory/common-reserved.yaml | 71 +++ > 1 file changed, 71 insertions(+) > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml > b/dtschema/schemas/reserved-memory/common-reserved.yaml > new file mode 100644 > index 000..4889f59 > --- /dev/null > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common memory reservations > + > +description: | > + Specifies that the reserved memory region can be used for the purpose > + indicated by its compatible string. > + > + Clients may reuse this reserved memory if they understand what it is for, > + subject to the notes below. > + > +maintainers: > + - Simon Glass > + > +allOf: > + - $ref: reserved-memory.yaml > + > +properties: > + compatible: > +description: | > + This describes some common memory reservations: > + > + acpi-reclaim: Contains ACPI tables; memory may be reclaimed when the > + tables are no-longer needed I think you are mixing 2 things with the name here. What the memory contains and what to do with it. You don't need the latter. The consumer of the region will know what to do with it if anything based on knowing what is in the region. For example, The DTB passed to the OS is typically in a reserved region (probably still /mem-reserve/ though). The DTB may remain there forever or the OS could copy it somewhere else and free the reserved region. The Linux kernel does both depending on the arch. (Of course there is no "dtb" compatible because we have to pass the location of the dtb to even find the reserved regions in the first place.) So the question here is whether just "acpi" (or "acpi-tables"?) would be explicit enough? > + acpi-nvs: Contains ACPI Non-volatile-storage data; memory may be > + reclaimed when the tables are no-longer needed No need to say anything about reclaiming. I know some ACPIisms (e.g. DSDT), but I don't know what NVS or "Non-volatile-storage data" is in an ACPI context. > + boot-code: Contains code used for booting; memory may be reclaimed > by > + the OS when it is running > + boot-code: Contains data used for booting; memory may be reclaimed > by boot-data? > + the OS when it is running I thought these were for stages before we get to OS? > + runtime-code: Contains code used for interacting with the system > when > + running; memory may be reclaimed if this code is not called > + runtime-data: Contains data used for interacting with the system > when > + running; memory may be reclaimed if the runtime code is not used "boot" vs. "runtime" seem too vague. However, if these mean EFI boot time services and runtime services, then I understand exactly what they are. In that case dropping 'uefi,' was a mistake. But EFI has its own way to define these regions, right? Rob
Re: [PATCH] bmips: Add Inteno XG6846 board
On 9/20/23 09:42, Linus Walleij wrote: This adds support for the Inteno XG6846 board based on the Broadcom MIPS 6328 SoC. The default boot will read a uImage from flash and boot it. Cc: Daniel Schwierzeck Signed-off-by: Linus Walleij --- arch/mips/dts/Makefile | 1 + arch/mips/dts/inteno,xg6846.dts | 57 ++ arch/mips/mach-bmips/Kconfig| 12 + board/inteno/xg6846/Kconfig | 12 + board/inteno/xg6846/MAINTAINERS | 6 +++ board/inteno/xg6846/Makefile| 3 ++ board/inteno/xg6846/xg6846.c| 6 +++ configs/inteno_xg6846_ram_defconfig | 74 + include/configs/inteno_xg6846.h | 8 9 files changed, 179 insertions(+) create mode 100644 arch/mips/dts/inteno,xg6846.dts create mode 100644 board/inteno/xg6846/Kconfig create mode 100644 board/inteno/xg6846/MAINTAINERS create mode 100644 board/inteno/xg6846/Makefile create mode 100644 board/inteno/xg6846/xg6846.c create mode 100644 configs/inteno_xg6846_ram_defconfig create mode 100644 include/configs/inteno_xg6846.h if you remove board/inteno/xg6846/Makefile and board/inteno/xg6846/xg6846.c: Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH] bmips: Add Inteno XG6846 board
On 9/20/23 20:55, Tom Rini wrote: On Wed, Sep 20, 2023 at 08:51:07PM +0200, Linus Walleij wrote: On Wed, Sep 20, 2023 at 4:22 PM Tom Rini wrote: + * This is a diet version of the device tree from Linux, + * suitable for U-Boot. + */ We shouldn't need a diet version of the tree. If it's reasonably done and stable in the kernel, we can even move towards just passing the U-Boot tree along to Linux. The device tree is not stable in the kernel. It exists in OpenWrt and the creators of the bmips target are kind of absent for the moment. The reason it is not in Linux is that the "switch ethernet" driver and bindings need to be upstreamed before the device trees can be upstreamed. But I can try to bring in more of it for sure :) Just like ARM the goal is just to drop in the kernel dts here. I guess this approach works well for ARM but not for MIPS. Most MIPS consumer boards are just maintained in OpenWRT but not in mainline Linux. And there are a few boards which have been just mainlined in U-Boot but not Linux so them also don't have a stable Linux DT. As MIPS is a dead architecture I suggest to just go with the minimal DT suited for U-Boot ;) +++ b/board/inteno/xg6846/xg6846.c @@ -0,0 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2023 Linus Walleij + */ + +#include So basically just an empty object file. Can we just _not_ have something here, if we perhaps don't set SYS_BOARD? I assume if there's just nothing here the link rules fail. Admittedly my knowledge of U-Boot internals are not the best and this is a bit of a copy and paste job from board/comtrend/ar5387un/ar-5387un.c which looks like this and sets a bad example I suppose. Yeah, I didn't know we had someone doing that already here, whoops. I guess you are asking me to modify U-Boots build system to make the whole .c and Makefile inside a board subdir optional so we can delete all such empty boardfiles? Well, it'd sure be nice if we could avoid having a dummy C file. If it looks like a nightmare once you take a peek, we can just live with it. I just tested it, you can simply add an empty board/inteno/xg6846/Makefile and remove board/inteno/xg6846/xg6846.c. But you can also remove the Makefile. Just the Kconfig and MAINTAINERS file are needed. -- - Daniel
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Tue, Sep 19, 2023 at 3:26 PM Simon Glass wrote: > > Hi Rob, > > On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Jassi Brar > > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass > > > > > > wrote: > > > > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > > > > > > > > > > > > > > > I beg to differ. Devicetree is more than just hardware and > > > > > > > > > > always has > > > > > > > > > > been. See, for example the /chosen and /options nodes. > > > > > > > > > > > > > > > > > > There are exceptions... > > > > > > > > > > > > > > > > > > > > > > > > > We've been this over and over again and frankly it gets a bit > > > > > > > > annoying. > > > > > > > > It's called *DEVICE* tree for a reason. As Rob pointed out > > > > > > > > there are > > > > > > > > exceptions, but those made a lot of sense. Having arbitrary > > > > > > > > internal ABI > > > > > > > > stuff of various projects in the schema just defeats the > > > > > > > > definition of a > > > > > > > > spec. > > > > > > > > > > > > > > Our efforts should not just be about internal ABI, but working to > > > > > > > provide a consistent configuration system for all firmware > > > > > > > elements. > > > > > > > > > > > > > Sure, programmatically we can pass any data/info via DT, however it > > > > > > is > > > > > > only meant to map hardware features onto data structures. > > > > > > > > > > > > devicetree.org landing page > > > > > > "The devicetree is a data structure for describing hardware." > > > > > > > > > > > > devicetree-specification-v0.3.pdf Chapter-2 Line-1 > > > > > >"DTSpec specifies a construct called a devicetree to describe > > > > > > system hardware." > > > > > > > > > > But it doesn't say that it describes *only* hardware. And it does > > > > > describe more than just hardware. There is /chosen to specify > > > > > firmware configuration and there are several examples of device tree > > > > > bindings that describe non-discoverable firmware interfaces in the > > > > > Linux tree. And it has been that way since the days of IEEE 1275. > > > > > There are also bindings describing things like the firmware partition > > > > > layout. > > > > > > > > Yes. The exact title for 1275[1] is: IEEE Standard for Boot > > > > (Initialization Configuration) > > > > Firmware: Core Requirements and Practices > > > > > > > > I see "configuration" in there. However, in the OF case, it's > > > > generally how firmware configured the hardware and what it discovered. > > > > That's a little different than telling the OS how to configure the > > > > hardware which is what we do with FDT. > > > > > > For the /options node it says "The properties of this node are the > > > system’s configuration variables." > > > > > > Then there is section 7.4.4 which has a large list of options which > > > don't seem to be so narrowly defined. > > > > > > In any case, this is not quite the point, which IMO is that we need DT > > > to support firmware use cases, whether or not a 29-year-old spec > > > thought of it or not. In fact it is amazing to me how forward-looking > > > Open Firmware was. > > > > > > > Then there's stuff that's how > > > > to configure Linux which we try to reject. > > > > > > Fair enough: Linux has user-space for that. > > > > Yep, the question I usually ask is who needs to configure something > > and what determines the config. Changing things with sysfs is much > > easier than changing the DT provided by firmware. > > > > > > > > > > Once we get into configuration of the OS/client (including u-boot), > > > > making that an ABI is a lot harder and if we use DT for that, I don't > > > > think it should be an ABI. > > > > > > > > > > If we want to digress from the spec, we need the majority of > > > > > > developers to switch sides :) which is unlikely to happen and > > > > > > rightly > > > > > > so, imho. > > > > > > > > > > It isn't even clear what the spec is. There is the document you > > > > > reference above, there are the yaml files at > > > > > https://github.com/devicetree-org/dt-schema and then there are > > > > > additional yaml files in the Linux tree. As far as I know it isn't > > > > > written down anywhere that those are the only places where device tree > > > > > bindings can live. > > > > > > > > There's not any restriction. > > > > > > > > My intention with dtschema schemas is to only have "spec level" > > > > schemas. (Stuff we'd add to DTSpec (but don't because no one wants to > > > > write specs).) Hardware specific stuff lives somewhere else. That > > > > happens to be the Linux tree because that is where all the h/w support > > > > is
Re: [PATCH] RFT: mips: implement __udivdi3
Hi Linus,
On 9/18/23 08:11, Linus Walleij wrote:
Squashfs wasn't compiling because the lldiv() directives
turn into __udivdi3 and we are using private libgcc.
This is just copied from the Linux kernel v6.6-rc1
arch/mips/include/asm/div64.h and then adjusted for
U-Boot.
After this squashfs compiles for MIPS.
Cc: Daniel Schwierzeck
Cc: Mauro Condarelli
Cc: Ralf Baechle
Signed-off-by: Linus Walleij
---
I can't test this because it didn't work for MTD devices
as I had expected, but I saw Mauro had this problem
before so I think I might have fixed it. I better put
the patch out there rather than let it sit on my drive.
thanks for the patch. IIRC the problem was due to the usage of a/b vs.
do_div(a,b). We already thought about two options: fix the SquashFS code
or add __udivdi3(). Because no upstream MIPS board enabled SquashFS,
this issue remained unresolved.
---
arch/mips/lib/Makefile | 2 +-
arch/mips/lib/udivdi3.c | 86 +
2 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/lib/udivdi3.c
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9ee1fcb5c702..1621cc9a1ff9 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -14,4 +14,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_CMD_GO) += boot.o
obj-$(CONFIG_SPL_BUILD) += spl.o
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o udivdi3.o
diff --git a/arch/mips/lib/udivdi3.c b/arch/mips/lib/udivdi3.c
new file mode 100644
index ..6a4ee5fa46ab
--- /dev/null
+++ b/arch/mips/lib/udivdi3.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2000, 2004, 2021 Maciej W. Rozycki
+ * Copyright (C) 2003, 07 Ralf Baechle (r...@linux-mips.org)
+ */
+
+#include "libgcc.h"
+
+/*
+ * No traps on overflows for any of these...
+ */
+
+#define do_div64_32(res, high, low, base) ({ \
+ unsigned long __cf, __tmp, __tmp2, __i; \
+ unsigned long __quot32, __mod32;\
+ \
+ __asm__(\
+ " .setpush\n"\
+ " .setnoat\n"\
+ " .setnoreorder \n"\
+ " move%2, $0 \n"\
+ " move%3, $0 \n"\
+ " b 1f \n"\
+ " li %4, 0x21\n"\
+ "0:\n"\
+ " sll $1, %0, 0x1 \n"\
+ " srl %3, %0, 0x1f\n"\
+ " or %0, $1, %5 \n"\
+ " sll %1, %1, 0x1 \n"\
+ " sll %2, %2, 0x1 \n"\
+ "1:\n"\
+ " bnez%3, 2f \n"\
+ " sltu %5, %0, %z6 \n"\
+ " bnez%5, 3f \n"\
+ "2:\n"\
+ " addiu %4, %4, -1 \n"\
+ " subu%0, %0, %z6 \n"\
+ " addiu %2, %2, 1 \n"\
+ "3:\n"\
+ " bnez%4, 0b \n"\
+ " srl%5, %1, 0x1f\n"\
+ " .setpop" \
+ : "=" (__mod32), "=" (__tmp), \
+ "=" (__quot32), "=" (__cf), \
+ "=" (__i), "=" (__tmp2) \
+ : "Jr" (base), "0" (high), "1" (low));\
+ \
+ (res) = __quot32; \
+ __mod32;\
+})
+
+#define __div64_32(n, base) ({ \
+ unsigned long __upper, __low, __high, __radix; \
+ unsigned long long __quot; \
+ unsigned long long __div; \
+ unsigned long __mod;
[PATCH v7 3/3] x86: doc: Update summaries and add links
Refresh the summary information so it is more up-to-date. Add links to the coreboot and slimbootloader docs. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v7: - Drop patches previously applied - Rebase to x86/next Changes in v2: - Add new patch - Add new patch doc/arch/x86/x86.rst | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index 3525ae8e27af..f67216d6ce02 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -11,9 +11,9 @@ including supported boards, build instructions, todo list, etc. Status -- U-Boot supports running as a `coreboot`_ payload on x86. So far only Link -(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should -work with minimal adjustments on other x86 boards since coreboot deals with -most of the low-level details. +(Chromebook Pixel), Brya (Alder Lake Chromebook) and `QEMU`_ x86 targets have +been tested, but it should work with minimal adjustments on other x86 boards +since coreboot deals with most of the low-level details. U-Boot is a main bootloader on Intel Edison board. @@ -32,12 +32,14 @@ are supported: - Link (Ivy Bridge - Chromebook Pixel) - Minnowboard MAX - Samus (Broadwell - Chromebook Pixel 2015) + - Coral (Apollo Lake Chromebooks circa 2017) - QEMU x86 (32-bit & 64-bit) As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks -for more details. +for more details. Finally, U-Boot can boot Linux distributions with a UEFI +interface. Build Instructions for U-Boot as BIOS replacement (bare mode) - @@ -438,9 +440,10 @@ for details of EFI support in U-Boot. Chain-loading - -U-Boot can be chain-loaded from another bootloader, such as coreboot or -Slim Bootloader. Typically this is done by building for targets 'coreboot' or -'slimbootloader'. +U-Boot can be chain-loaded from another bootloader, such as +:doc:`../../board/coreboot/index` coreboot or +:doc:`../../board/intel/slimbootloader`. Typically this is done by building for +targets 'coreboot' or 'slimbootloader'. For example, at present we have a 'coreboot' target but this runs very different code from the bare-metal targets, such as coral. There is very little -- 2.42.0.515.g380fc7ccd1-goog
[PATCH v7 2/3] x86: coreboot: Drop USB init on startup
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired. Drop this code so that it is possible to choose whether to init USB or not. Use the existing USE_PREBOOT mechanism instead. Signed-off-by: Simon Glass --- Changes in v7: - Add docs about how USB keyboard works on coreboot Changes in v5: - Make use of the uSE_PREBOOT mechanism arch/x86/cpu/coreboot/Kconfig| 1 + arch/x86/cpu/coreboot/coreboot.c | 4 doc/board/coreboot/coreboot.rst | 7 +++ 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE + imply USE_PREBOOT select BINMAN if X86_64 endif diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index da43d66e95d7..82fe4c71cd27 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -86,10 +86,6 @@ static int last_stage_init(void) if (IS_ENABLED(CONFIG_SPL_BUILD)) return 0; - /* start usb so that usb keyboard can be used as input device */ - if (IS_ENABLED(CONFIG_USB_KEYBOARD)) - usb_init(); - board_final_init(); return 0; diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 10ef78bb5ada..10a251c2b64f 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -85,6 +85,13 @@ build in `$CBDIR`:: This allows booting and installing various distros, many of which are 64-bit-only, so cannot work with the 32-bit 'coreboot' build. +USB keyboard + + +The `CONFIG_USE_PREBOOT` option is enabled by default, meaning that USB starts +up just before the command-line starts. This allows user interaction on +non-laptop devices which use a USB keyboard. + CBFS access --- -- 2.42.0.515.g380fc7ccd1-goog
[PATCH v7 1/3] fixup: Move python control earlier in Makefile
Move this control into the common area of the main Makefile, so it applies to non-build rules as well. This allows 'make mrproper' to handle python files as it should. This should be squashed into: 65a33eba10d Allow Python packages to be dropped Signed-off-by: Simon Glass --- Changes in v7: - Add new fixup patch to move python control earlier in Makefile Makefile | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 264f31bfe473..efbaf434df48 100644 --- a/Makefile +++ b/Makefile @@ -485,6 +485,15 @@ export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o\ export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \ --exclude CVS --exclude .pc --exclude .hg --exclude .git +export PYTHON_ENABLE + +# This is y if U-Boot should not build any Python tools or libraries. Typically +# you would need to set this if those tools/libraries (typically binman and +# pylibfdt) cannot be built by your environment and are provided separately. +ifeq ($(NO_PYTHON),) +PYTHON_ENABLE=y +endif + # === # Rules shared between *config targets and build targets @@ -646,20 +655,12 @@ export CFLAGS_NON_EFI # Compiler flags to remove when building EFI app export EFI_TARGET # binutils target if EFI is natively supported export LTO_ENABLE -export PYTHON_ENABLE # This is y if LTO is enabled for this build. See NO_LTO=1 to disable LTO ifeq ($(NO_LTO),) LTO_ENABLE=$(if $(CONFIG_LTO),y) endif -# This is y if U-Boot should not build any Python tools or libraries. Typically -# you would need to set this if those tools/libraries (typically binman and -# pylibfdt) cannot be built by your environment and are provided separately. -ifeq ($(NO_PYTHON),) -PYTHON_ENABLE=y -endif - # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use # that (or fail if absent). Otherwise, search for a linker script in a # standard location. -- 2.42.0.515.g380fc7ccd1-goog
[PATCH v7 0/3] x86: efi: Fixes and improvements for coreboot
This little series fixes various bugs and annoyances in coreboot and coreboot64. With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros. - Make coreboot64 debug UART start reliably - Avoid the long USB-init delay on startup - Correct the timer speed on coreboo64 - Fix a bootstd cros bug (will likely be squashed into another patch) - Fix the terribly slow console scrolling With v2 I have also brought in some lost x86 patches so they are all in one series. Changes in v7: - Add new fixup patch to move python control earlier in Makefile - Add docs about how USB keyboard works on coreboot - Drop patches previously applied - Rebase to x86/next Changes in v5: - Make use of the uSE_PREBOOT mechanism Changes in v2: - Add new patch - Add new patch Simon Glass (3): fixup: Move python control earlier in Makefile x86: coreboot: Drop USB init on startup x86: doc: Update summaries and add links Makefile | 17 + arch/x86/cpu/coreboot/Kconfig| 1 + arch/x86/cpu/coreboot/coreboot.c | 4 doc/arch/x86/x86.rst | 17 ++--- doc/board/coreboot/coreboot.rst | 7 +++ 5 files changed, 27 insertions(+), 19 deletions(-) -- 2.42.0.515.g380fc7ccd1-goog
[GIT PULL] xilinx patches for v2024.01-rc1 v2
Hi Tom, please pull these patches to your next branch. I am sending it as v2 in spite of v1 didn't really went through. I created tag but CI failed because of sandbox CI trace failure. After fixing it and reviewing by Simon I am adding it to be able to extend ofnode functions for getting functionality for our SOCs. All non Xilinx patches are reviewed mostly by Simon. There are other pending changes which are still under review which should go to v2024.01 but I wanted to get this part done because amount of patches is bigger than I would like have. I was thinking about sending cmd/flash_is_unloacked fix to 2023.07 but it looks like none is actually using spi locking that's why it shouldn't be a problem to fix in 2024.01. But feel free to pick it up to master if you like. Thanks, Michal The following changes since commit c58ee1c9946a1550b1f6fee2b25da9ecc89baf71: Merge branch '2023-09-19-tidy-up-some-kconfig-options' into next (2023-09-19 17:44:18 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2024.01-rc1-v2 for you to fetch changes up to a3ade3dae4d93f9b5282ddb4885d69161729ec6d: spi: zynqmp_qspi: Workaround for small data cache issue (2023-09-21 13:20:12 +0200) Xilinx changes for v2024.01-rc1 clk: - Dont return error when assigned-clocks is empty or missing dm: - Support reading a single indexed u64 value - Add support for reading bootscript address/flash address from DT cmd: - Fix flash_is_unlocked API fpga: - Define fpga_load() for debug build global: - U-Boot project name cleanup (next2) net: - zynq_gem: Use generic_phy_valid() helper - axienet: Convert to ofnode functions - gmii2rgmii: Read bridge address from DT pytest: - skip tpm2_startup when env__tpm_device_test_skip=True spi-nor: - Add mx25u25635f support - zynqmp_qspi: Tune cache behavior trace: - Fix flyrecord alignment issue xilinx: - Move scriptaddr to DT as bootscr-address - Pick script_offset_f/script_size_f from DT as bootscr-flash-offset/size - Do not generate distro boot variables if disabled versal: - Extend memory ranges to cover HBM - Enable TPM, sha1sum and KASLRSEED - Fix distroboot prioritization in connection to available devices - Clean mini targets bootcommand - Fix clock driver versal-net: - Enable TPM, sha1sum and KASLRSEED - Fix distroboot prioritization in connection to available devices zynqmp; - Allow AES to run from SPL - Enable CMD_KASLRSEED - Add proper dependencies for USB and remove ZYNQMP_USB - Fix user si570 default frequency for zcu* boards - Cover SOM rev2 revision - Various DT changes - Add firmware and pinctrl support for tristate configuration (high impedance/output enable) - Add output-enable pins to SOMs - Fix distroboot prioritization in connection to available devices - Read bootscript address/flash address from DT - Fix pcap_prog address Algapally Santosh Sagar (1): xilinx: board: Add support to pick bootscr address from DT Amit Kumar Mahapatra (1): arm64: versal: Add no-wp DT property in OSPI flash node Ashok Reddy Soma (5): firmware: zynqmp: Add support to check feature pinctrl: zynqmp: Add version check for TRISTATE configuration pinctrl: zynqmp: Add support for output-enable and bias-high-impedance clk: Dont return error when assigned-clocks is empty or missing spi: zynqmp_qspi: Change flush cache to invalidate cache Chanho Park (1): fpga: define dummy fpga_load function for debug build Christian Taedcke (1): xilinx: zynqmp: Extract aes operation into new file Lukas Funke (1): arm64: zynqmp: Corrected pcap_prog register address Maxim Kochetkov (1): net: axi_emac: Convert to ofnode functions Michal Simek (16): xilinx: Remove scriptaddr from config files and move it to DT arm64: zynqmp: Setup default si570 frequency to 156.25MHz arm64: zynqmp: Add support for K26 rev2 boards dm: core: support reading a single indexed u64 value test/py: tpm2: skip tpm2_startup when env__tpm_device_test_skip=True dm: core: ofnode: Add ofnode_read_bootscript_address() dm: core: ofnode: Add ofnode_read_bootscript_flash() xilinx: board: Add support to pick bootscr flash offset/size from DT arm64: versal: Do not define boot command for mini configurations arm64: xilinx: Guard distro boot variable generation global: Use proper project name U-Boot (next2) dm: core: ofnode: Fix error message in ofnode_read_bootscript_address/flash() arm64: zynqmp: Rename xlnx, mio_bank to xlnx, mio-bank for DLC21 trace: Use 64bit variable for start and len trace: Move trace_clocks description above record offset calculation trace: Fix alignment logic in flyrecord header Neal Frager (2): drivers/mtd/spi/spi-nor-ids.c: add
Re: [PATCH v5 00/20] x86: efi: Fixes and improvements for coreboot
Hi Bin, On Thu, 21 Sept 2023 at 00:31, Bin Meng wrote: > > Hi Simon, > > On Thu, Sep 21, 2023 at 1:27 PM Bin Meng wrote: > > > > Hi Simon, > > > > On Wed, Sep 20, 2023 at 11:00 AM Simon Glass wrote: > > > > > > This little series fixes various bugs and annoyances in coreboot and > > > coreboot64. > > > > > > With this both coreboot and coreboot64 start up and work reasonably well > > > on Brya (x86 Chromebook) and U-Boot can boot common Linux distros. > > > > > > - Make coreboot64 debug UART start reliably > > > - Avoid the long USB-init delay on startup > > > - Correct the timer speed on coreboo64 > > > - Fix a bootstd cros bug (will likely be squashed into another patch) > > > - Fix the terribly slow console scrolling > > > > > > With v2 I have also brought in some lost x86 patches so they are all in > > > one series. > > > > > > Changes in v5: > > > - Use 'lzma' instead of 'LZMA' > > > - Drop unwanted space > > > - Correct 'teechnique' typo in commit message > > > - Make use of the uSE_PREBOOT mechanism > > > > > > Changes in v4: > > > - Fix arm and riscv > > > - Rewrite this to use events instead > > > > > > Changes in v3: > > > - Allow SMBIOS if EFI_LOADER is enabled > > > - Reword the help > > > - Use log_debug() to show the message > > > - Squash in the next patch > > > > > > Changes in v2: > > > - Update the malloc size too > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > - Add new patch > > > > > > Simon Glass (20): > > > x86: coreboot: Add IDE and SATA > > > x86: coreboot: Enable standard boot > > > x86: coreboot: Rearrange arch_cpu_init() > > > x86: Set the CPU vendor in SPL > > > x86: Allow APCI in SPL > > > x86: coreboot: Look for DBG2 UART in SPL too > > > x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 > > > x86: coreboot: Drop USB init on startup > > > x86: coreboot: Align options between coreboot and coreboot64 > > > x86: coreboot: Enable VIDEO_COPY > > > efi: x86: Correct the condition for installing ACPI tables > > > x86: smbios: Add a Kconfig indicating SMBIOS-table presence > > > bootstd: Keep track of use of usb stop > > > Record the position of the SMBIOS tables > > > efi: Use the installed SMBIOS tables > > > x86: coreboot: Record the position of the SMBIOS tables > > > x86: doc: Move into its own directory > > > x86: doc: Update summaries and add links > > > x86: doc: Split out manual booting into its own file > > > x86: doc: coreboot: Mention 64-bit Linux distros > > > > > > > Patch #8 needs to respin to address PREBOOT comment > > Path#18 does not apply. > > > > Patch#13, 15 v6 version are applied. > > > > Reset patches in this series are applied to u-boot-x86/next, thanks! > > The CI still fails on u-boot-x86/next which is already rebased on origin/next. > https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17784 OK, I found the problem. I will include a fixup patch in v7. Regards, Simon
Re: [PATCH v1] fs: Fix SPL build if FS_LOADER is enabled
On Thu, 2023-09-14 at 12:39 -0400, Tom Rini wrote:
> On Thu, Sep 14, 2023 at 09:35:15PM +0530, Mayuresh Chitale wrote:
>
> > If FS_LOADER is enabled for the SPL then the build fails with the
> > error:
> >
> > fs/fs.o:(.data.rel.fstypes+0x128):
> > undefined reference to `smh_fs_set_blk_dev'
> > fs/fs.o:(.data.rel.fstypes+0x140):
> > undefined reference to `smh_fs_size'
> > fs/fs.o:(.data.rel.fstypes+0x148):
> > undefined reference to `smh_fs_read'
> > fs/fs.o:(.data.rel.fstypes+0x150):
> > undefined reference to `smh_fs_write'
> >
> > Fix the error by populating the semihosting entry in the fs_types
> > array
> > only for non-SPL builds.
> >
> > Reviewed-by: Heinrich Schuchardt > >
> > Signed-off-by: Mayuresh Chitale
> > ---
> > fs/fs.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/fs.c b/fs/fs.c
> > index 2b815b1db0..074db4b20f 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -256,6 +256,7 @@ static struct fstype_info fstypes[] = {
> > .ln = fs_ln_unsupported,
> > },
> > #endif
> > +#ifndef CONFIG_SPL_BUILD
> > #ifdef CONFIG_SEMIHOSTING
> > {
> > .fstype = FS_TYPE_SEMIHOSTING,
>
> This should be CONFIG_IS_ENABLED(SEMIHOSTING).
Ok. I will update it.
>
Re: [PATCH v1 1/2] part: Add a function to find ESP partition
On Thu, 2023-09-14 at 12:29 -0400, Tom Rini wrote:
> On Thu, Sep 14, 2023 at 03:38:20PM +0530, Mayuresh Chitale wrote:
> > If a disk has an EFI system partition (ESP) then it can be used to
> > locate the boot files. Add a function to find the ESP.
> >
> > Signed-off-by: Mayuresh Chitale
> > Reviewed-by: Heinrich Schuchardt > >
> > ---
> > disk/part.c| 16
> > include/part.h | 10 ++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/disk/part.c b/disk/part.c
> > index 72241b7b23..2be0866671 100644
> > --- a/disk/part.c
> > +++ b/disk/part.c
> > @@ -841,3 +841,19 @@ int part_get_bootable(struct blk_desc *desc)
> >
> > return 0;
> > }
> > +
> > +int part_get_esp(struct blk_desc *desc)
> > +{
> > + struct disk_partition info;
> > + int p;
> > +
> > + for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
> > + int ret;
> > +
> > + ret = part_get_info(desc, p, );
> > + if (!ret && (info.bootable &
> > PART_EFI_SYSTEM_PARTITION))
> > + return p;
> > + }
> > +
> > + return 0;
> > +}
> > diff --git a/include/part.h b/include/part.h
> > index db34bc6bb7..036f9fd762 100644
> > --- a/include/part.h
> > +++ b/include/part.h
> > @@ -689,6 +689,13 @@ int part_get_type_by_name(const char *name);
> > * @return first bootable partition, or 0 if there is none
> > */
> > int part_get_bootable(struct blk_desc *desc);
> > +/**
>
> Missing blank line?
>
Ok, I will add it.
Re: [PATCH v1 2/2] spl: Add support for booting from ESP
On Thu, 2023-09-14 at 12:29 -0400, Tom Rini wrote:
> On Thu, Sep 14, 2023 at 03:38:21PM +0530, Mayuresh Chitale wrote:
>
> > Some platforms as described by EBBR specification may store images
> > in
> > the FIRMWARE directory of the UEFI system partition(ESP). Add
> > support
> > to boot from the EFI system partition if it is enabled for a
> > platform.
> >
> > Signed-off-by: Mayuresh Chitale
> [snip]
> > +config SPL_ESP_BOOT
> > + bool "Load next stage boot image from the UEFI system
> > partition"
> > + select SPL_PARTITION_TYPE_GUID
> > + help
> > + When enabled, first try to boot from the UEFI system
> > partition as
> > + described in the Ch.4 of the EBBR specification.
>
> We need to select this by perhaps BOOT_DEFAULTS or BOOTMETH_DISTRO,
> whatever is supposed to signify that yes, this is going to be a
> SystemReady IR (or higher) compliant build.
I am not sure about the SystemReady compliance but I think the config
option can be enabled for those platforms which require it.
> [snip]
> > int spl_blk_load_image(struct spl_image_info *spl_image,
> >struct spl_boot_device *bootdev,
> >enum uclass_id uclass_id, int devnum, int
> > partnum)
> > {
> > const char *filename = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME;
> > - struct legacy_img_hdr *header;
> [snip]
> > @@ -63,24 +88,26 @@ int spl_blk_load_image(struct spl_image_info
> > *spl_image,
> > }
> >
> > blk_show_device(uclass_id, devnum);
> > - header = spl_get_load_buffer(-sizeof(*header),
> > sizeof(*header));
> > -
> [snip]
>
> Is this an artifact of Sean's patch series where "header" is no
> longer
> actually used? As-is this won't compile on top of next (which is
> where
> given Sean's feedback, the series needs to be rebased upon anyhow).
Yes, I will rebase on the latest next without Sean's series and resend
the patch.
> > + /*
> > +* First try to boot from EFI System partition. In case of
> > failure,
> > +* fall back to the configured partition.
> > +*/
>
> I don't know that this is the right behavior. If we're configured to
> boot from partition X, we boot from partition X. If we're configured
> to
> find the ESP and use that, we find and use that.
This is to maintain compatibility and make more attempts to boot. So
the same SPL binary can load images from devices with or without the
ESP.
[PATCH v8 2/2] serial: zynqmp: Fetch baudrate from dtb and update
From: Algapally Santosh Sagar
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Also add test to cover this new function.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
---
arch/sandbox/dts/test.dts | 1 +
doc/README.serial_dt_baud | 41
drivers/core/ofnode.c | 18 +
drivers/serial/Kconfig | 9 +++
drivers/serial/serial-uclass.c | 49 ++
include/dm/ofnode.h| 14 --
include/env_default.h | 6 -
include/serial.h | 7 +
test/dm/serial.c | 1 +
9 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 doc/README.serial_dt_baud
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f351d5cb84..deb57f146a 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1499,6 +1499,7 @@
other-node = "/some-bus/c-test@5";
int-values = <0x1937 72993>;
u-boot,acpi-ssdt-order = <_test2 _test1>;
+ stdout-path = "serial0:115200n8";
chosen-test {
compatible = "denx,u-boot-fdt-test";
reg = <9 1>;
diff --git a/doc/README.serial_dt_baud b/doc/README.serial_dt_baud
new file mode 100644
index 00..f8768d0e1b
--- /dev/null
+++ b/doc/README.serial_dt_baud
@@ -0,0 +1,41 @@
+Fetch serial baudrate from DT
+-
+
+To support fetching of baudrate from DT, the following is done:-
+
+The baudrate configured in Kconfig symbol CONFIG_BAUDRATE is taken by default
by serial.
+If change of baudrate is required then the Kconfig symbol CONFIG_BAUDRATE
needs to
+changed and U-Boot recompilation is required or the U-Boot environment needs
to be updated.
+
+To avoid this, add support to fetch the baudrate directly from the device tree
file and
+update the environment.
+
+The default environment stores the default baudrate value. When default
baudrate and dtb
+baudrate are not same glitches are seen on the serial.
+So, the environment also needs to be updated with the dtb baudrate to avoid
the glitches on
+the serial which is enabled by OF_SERIAL_BAUD.
+
+The Kconfig SPL_ENV_SUPPORT needs to be enabled to allow patching in SPL.
+
+The Kconfig DEFAULT_ENV_IS_RW which is enabled by OF_SERIAL_BAUD with making
the environment
+writable.
+
+The ofnode_read_baud() function parses and fetches the baudrate value from the
DT. This value
+is validated and updated to baudrate during serial init. Padding is added at
the end of the
+default environment and the dt baudrate is updated with the latest value.
+
+Example:-
+
+The serial port options are of the form "pnf", where "" is the baud
rate, "p" is parity ("n", "o", or "e"),
+"n" is number of bits, and "f" is flow control ("r" for RTS or omit it).
Default is "115200n8".
+
+chosen {
+ bootargs = "earlycon console=ttyPS0,115200 clk_ignore_unused
root=/dev/ram0 rw init_fatal_sh=1";
+ stdout-path = "serial0:115200n8";
+ };
+
+From the chosen node, stdout-path property is obtained as string.
+
+ stdout-path = "serial0:115200n8";
+
+The string is parsed to get the baudrate 115200. This string is converted to
integer and updated to the environment.
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af..42f51ca93c 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -895,6 +895,24 @@ ofnode ofnode_get_chosen_node(const char *name)
return ofnode_path(prop);
}
+int ofnode_read_baud(void)
+{
+ const char *str, *p;
+ u32 baud;
+
+ str = ofnode_read_chosen_string("stdout-path");
+ if (!str)
+ return -EINVAL;
+
+ /* Parse string serial0:115200n8 */
+ p = strchr(str, ':');
+ if (!p)
+ return -EINVAL;
+
+ baud = dectoul(p + 1, NULL);
+ return baud;
+}
+
const void *ofnode_read_aliases_prop(const char *propname, int *sizep)
{
ofnode node;
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 4d27034c3f..7fdf600dc5 100644
--- a/drivers/serial/Kconfig
+++
[PATCH v8 1/2] configs: Add support in Kconfig and convert for armada boards
From: Algapally Santosh Sagar
Move the DEFAULT_ENV_IS_RW to Kconfig for easier configuration.
Hence, add the CONFIG_DEFAULT_ENV_IS_RW config to the defconfig files
to allow enabling them for armada boards.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
Reviewed-by: Simon Glass
---
configs/eDPU_defconfig | 1 +
configs/mvebu_db-88f3720_defconfig | 1 +
configs/mvebu_espressobin-88f3720_defconfig | 1 +
configs/uDPU_defconfig | 1 +
drivers/serial/Kconfig | 6 ++
include/configs/mvebu_armada-37xx.h | 1 -
include/env_default.h | 2 +-
include/env_internal.h | 2 +-
8 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/configs/eDPU_defconfig b/configs/eDPU_defconfig
index 77ea2b2eec..61fb9bd2a5 100644
--- a/configs/eDPU_defconfig
+++ b/configs/eDPU_defconfig
@@ -21,6 +21,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/configs/mvebu_db-88f3720_defconfig
b/configs/mvebu_db-88f3720_defconfig
index 829567014f..e6fb80167a 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -22,6 +22,7 @@ CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/configs/mvebu_espressobin-88f3720_defconfig
b/configs/mvebu_espressobin-88f3720_defconfig
index fc394a7e9d..64ee99d64b 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -24,6 +24,7 @@ CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_BOARD_LATE_INIT=y
diff --git a/configs/uDPU_defconfig b/configs/uDPU_defconfig
index fa1989518b..4d3d53ac7e 100644
--- a/configs/uDPU_defconfig
+++ b/configs/uDPU_defconfig
@@ -21,6 +21,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 8c54bc9c47..4d27034c3f 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -24,6 +24,12 @@ config BAUDRATE
in the SPL stage (most drivers) or for choosing a default baudrate
in the absence of an environment setting (serial_mxc.c).
+config DEFAULT_ENV_IS_RW
+ bool "Make default environment as writable"
+ help
+ Select this to enable to make default environment writable. This
+ allows modifying the default environment.
+
config REQUIRE_SERIAL_CONSOLE
bool "Require a serial port for console"
# Running without a serial console is not supported by the
diff --git a/include/configs/mvebu_armada-37xx.h
b/include/configs/mvebu_armada-37xx.h
index 76e148f55e..18b55be0d8 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -30,7 +30,6 @@
/*
* Environment
*/
-#define DEFAULT_ENV_IS_RW /* required for configuring default
fdtfile= */
#ifdef CONFIG_MMC
#define BOOT_TARGET_DEVICES_MMC(func, i) func(MMC, mmc, i)
diff --git a/include/env_default.h b/include/env_default.h
index b16c22d5a2..227cad7c34 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -21,7 +21,7 @@ env_t embedded_environment __UBOOT_ENV_SECTION__(environment)
= {
{
#elif defined(DEFAULT_ENV_INSTANCE_STATIC)
static char default_environment[] = {
-#elif defined(DEFAULT_ENV_IS_RW)
+#elif defined(CONFIG_DEFAULT_ENV_IS_RW)
char default_environment[] = {
#else
const char default_environment[] = {
diff --git a/include/env_internal.h b/include/env_internal.h
index 6a69494646..fcb464263f 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -89,7 +89,7 @@ typedef struct environment_s {
extern env_t embedded_environment;
#endif /* ENV_IS_EMBEDDED */
-#ifdef DEFAULT_ENV_IS_RW
+#ifdef CONFIG_DEFAULT_ENV_IS_RW
extern char default_environment[];
#else
extern const char default_environment[];
--
2.25.1
[PATCH v8 0/2] Add support to fetch baudrate from dtb
In this patch series - Add support in Kconfig and convert for armada boards - Fetch baudrate from the dtb and update Changes in v8: - Added test to cover fetch_baud_from_dtb. - Changed this check_valid_baudrate() to static and removed from serial.h - Fixed the compilation error. Changes in v7: - Updated the commit message. Changes in v6: - Changed Kconfig OF_SERIAL_DT_BAUD to OF_SERIAL_BAUD. - Added IS_ENABLED() in place of #ifdef CONFIG_OF_SERIAL_AUD Changes in v5: - Adding DEFAULT_ENV_IS_RW Kconfig in missing files - Updating DEFAULT_ENV_IS_RW to CONFIG_DEFAULT_ENV_IS_RW Changes in v4: - Moved SERIAL_DT_BAUD to another patch - Added doc file for fetching serial baudrate from DT. - Changed Kconfig SERIAL_DT_BAUD to OF_SERIAL_DT_BAUD - Added function docs wherever required. - Moved changes from fdtdec api to ofnode - Changed serial_get_valid_baudrate to check_valid_baudrate - Added function fetch_baud_from_dtb to fetch baud from DT - Used dectoul() for parsing baudrate Changes in v3: - Add SERIAL_DT_BAUD to Kconfig - Moved DEFAULT_ENV_IS_RW to Kconfig also updated armada files - Moved filler changes from zynqmp.h to generic file env_default.h - Removed ENV_RW_FILLER and added padding in the generic file env_default.h. - Print baudrate parameter properly when SERIAL_DT is enabled. Changes in v2: - Changed to #ifdef from #if CONFIG_IS_ENABLED to enable patching in spl. - Added SPL_ENV_SUPPORT dependency in SERIAL_DT_BAUD to allow SPL compilation. - Moved DEFAULT_ENV_IS_RW to Kconfig also updated armada files - Moved ENV_RW_FILLER to generic file env_default.h. - Increased the ENV_RW_FILLER padding to support 800 baud. Algapally Santosh Sagar (2): configs: Add support in Kconfig and convert for armada boards serial: zynqmp: Fetch baudrate from dtb and update arch/sandbox/dts/test.dts | 1 + configs/eDPU_defconfig | 1 + configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_espressobin-88f3720_defconfig | 1 + configs/uDPU_defconfig | 1 + doc/README.serial_dt_baud | 41 + drivers/core/ofnode.c | 18 drivers/serial/Kconfig | 15 +++ drivers/serial/serial-uclass.c | 49 + include/configs/mvebu_armada-37xx.h | 1 - include/dm/ofnode.h | 14 +- include/env_default.h | 8 +++- include/env_internal.h | 2 +- include/serial.h| 7 +++ test/dm/serial.c| 1 + 15 files changed, 155 insertions(+), 6 deletions(-) create mode 100644 doc/README.serial_dt_baud -- 2.25.1
[PATCH] usbarmory: Add DM_I2C and DM_SERIAL support
From: Andrej Rosano Use DM_I2C and DM_SERIAL as it is now mandatory. Signed-off-by: Andrej Rosano --- configs/usbarmory_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/usbarmory_defconfig b/configs/usbarmory_defconfig index 66c969f95e..277f055aef 100644 --- a/configs/usbarmory_defconfig +++ b/configs/usbarmory_defconfig @@ -29,7 +29,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_HOSTNAME=y CONFIG_HOSTNAME="usbarmory" -CONFIG_SYS_I2C_LEGACY=y +CONFIG_DM_I2C=y CONFIG_SYS_I2C_MXC=y CONFIG_FSL_IIM=y CONFIG_FSL_ESDHC_IMX=y @@ -39,6 +39,7 @@ CONFIG_PINCTRL_IMX5=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y CONFIG_USB=y CONFIG_USB_EHCI_MX5=y -- 2.42.0
[PATCH v3 8/8] arch: meson: use secure monitor driver
Now we have to use UCLASS_SM driver instead of
raw smc_call() function call.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
arch/arm/mach-meson/Kconfig | 1 +
arch/arm/mach-meson/sm.c| 110 +++-
2 files changed, 58 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 669ca09a00..d6c8905806 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -11,6 +11,7 @@ config MESON64_COMMON
select PWRSEQ
select MMC_PWRSEQ
select BOARD_LATE_INIT
+ select MESON_SM
imply CMD_DM
config MESON_GX
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
index b5dd6c6d39..914fd11c98 100644
--- a/arch/arm/mach-meson/sm.c
+++ b/arch/arm/mach-meson/sm.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,70 +19,62 @@
#include
#include
#include
+#include
-#define FN_GET_SHARE_MEM_INPUT_BASE0x8220
-#define FN_GET_SHARE_MEM_OUTPUT_BASE 0x8221
-#define FN_EFUSE_READ 0x8230
-#define FN_EFUSE_WRITE 0x8231
-#define FN_CHIP_ID 0x8244
-#define FN_PWRDM_SET 0x8293
-
-static void *shmem_input;
-static void *shmem_output;
-
-static void meson_init_shmem(void)
+static inline struct udevice *meson_get_sm_device(void)
{
- struct pt_regs regs;
-
- if (shmem_input && shmem_output)
- return;
+ struct udevice *dev;
+ int err;
- regs.regs[0] = FN_GET_SHARE_MEM_INPUT_BASE;
- smc_call();
- shmem_input = (void *)regs.regs[0];
-
- regs.regs[0] = FN_GET_SHARE_MEM_OUTPUT_BASE;
- smc_call();
- shmem_output = (void *)regs.regs[0];
+ err = uclass_first_device_err(UCLASS_SM, );
+ if (err) {
+ pr_err("Mesom SM device not found\n");
+ return ERR_PTR(err);
+ }
- debug("Secure Monitor shmem: 0x%p 0x%p\n", shmem_input, shmem_output);
+ return dev;
}
ssize_t meson_sm_read_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
- meson_init_shmem();
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_EFUSE_READ;
regs.regs[1] = offset;
regs.regs[2] = size;
- smc_call();
+ err = sm_call_read(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_READ, );
+ if (err < 0)
+ pr_err("Failed to read efuse memory (%d)\n", err);
- if (regs.regs[0] == 0)
- return -1;
-
- memcpy(buffer, shmem_output, min(size, regs.regs[0]));
-
- return regs.regs[0];
+ return err;
}
ssize_t meson_sm_write_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
-
- meson_init_shmem();
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
-memcpy(shmem_input, buffer, size);
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_EFUSE_WRITE;
regs.regs[1] = offset;
regs.regs[2] = size;
- smc_call();
+ err = sm_call_write(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_WRITE, );
+ if (err < 0)
+ pr_err("Failed to write efuse memory (%d)\n", err);
- return regs.regs[0];
+ return err;
}
#define SM_CHIP_ID_LENGTH 119
@@ -90,18 +83,21 @@ ssize_t meson_sm_write_efuse(uintptr_t offset, void
*buffer, size_t size)
int meson_sm_get_serial(void *buffer, size_t size)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ u8 id_buffer[SM_CHIP_ID_LENGTH];
+ int err;
- meson_init_shmem();
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_CHIP_ID;
- regs.regs[1] = 0;
- regs.regs[2] = 0;
+ err = sm_call_read(dev, id_buffer, SM_CHIP_ID_LENGTH,
+ MESON_SMC_CMD_CHIP_ID_GET, );
+ if (err < 0)
+ pr_err("Failed to read serial number (%d)\n", err);
- smc_call();
-
- memcpy(buffer, shmem_output + SM_CHIP_ID_OFFSET,
- min_t(size_t, size, SM_CHIP_ID_SIZE));
+ memcpy(buffer, id_buffer + SM_CHIP_ID_OFFSET, size);
return 0;
}
@@ -141,13 +137,21 @@ int meson_sm_get_reboot_reason(void)
int meson_sm_pwrdm_set(size_t index, int cmd)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
+
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_PWRDM_SET;
[PATCH v3 7/8] arch: meson: sm: set correct order of the includes
The common.h header should always be first, followed by other headers in order, then headers with directories, then local files. Signed-off-by: Alexey Romanov Reviewed-by: Simon Glass --- arch/arm/mach-meson/sm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c index d600c64d0b..b5dd6c6d39 100644 --- a/arch/arm/mach-meson/sm.c +++ b/arch/arm/mach-meson/sm.c @@ -6,7 +6,10 @@ */ #include +#include #include +#include +#include #include #include #include @@ -14,10 +17,7 @@ #include #include #include -#include #include -#include -#include #define FN_GET_SHARE_MEM_INPUT_BASE0x8220 #define FN_GET_SHARE_MEM_OUTPUT_BASE 0x8221 -- 2.25.1
[PATCH v3 6/8] drivers: introduce Meson Secure Monitor driver
This patch adds an implementation of the Meson Secure Monitor
driver based on UCLASS_SM.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
MAINTAINERS | 1 +
drivers/sm/Kconfig| 7 ++
drivers/sm/Makefile | 1 +
drivers/sm/meson-sm.c | 198 ++
include/meson/sm.h| 19
5 files changed, 226 insertions(+)
create mode 100644 drivers/sm/meson-sm.c
create mode 100644 include/meson/sm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6c64427782..bdc364fd4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -158,6 +158,7 @@ F: drivers/net/phy/meson-gxl.c
F: drivers/adc/meson-saradc.c
F: drivers/phy/meson*
F: drivers/mmc/meson_gx_mmc.c
+F: drivers/sm/meson-sm.c
F: drivers/spi/meson_spifc.c
F: drivers/pinctrl/meson/
F: drivers/power/domain/meson-gx-pwrc-vpu.c
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
index 6cc6d55578..b4cc3f768e 100644
--- a/drivers/sm/Kconfig
+++ b/drivers/sm/Kconfig
@@ -1,2 +1,9 @@
config SM
bool "Enable Secure Monitor driver support"
+
+config MESON_SM
+ bool "Amlogic Secure Monitor driver"
+ depends on SM
+ default n
+ help
+ Say y here to enable the Amlogic secure monitor driver.
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
index af5f475c2b..da81ee898a 100644
--- a/drivers/sm/Makefile
+++ b/drivers/sm/Makefile
@@ -2,3 +2,4 @@
obj-y += sm-uclass.o
obj-$(CONFIG_SANDBOX) += sandbox-sm.o
+obj-$(CONFIG_MESON_SM) += meson-sm.o
diff --git a/drivers/sm/meson-sm.c b/drivers/sm/meson-sm.c
new file mode 100644
index 00..25adaf4560
--- /dev/null
+++ b/drivers/sm/meson-sm.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct meson_sm_cmd {
+ u32 smc_id;
+};
+
+#define SET_CMD(index, id) \
+ [index] = { \
+ .smc_id = (id), \
+ }
+
+struct meson_sm_data {
+ u32 cmd_get_shmem_in;
+ u32 cmd_get_shmem_out;
+ unsigned int shmem_size;
+ struct meson_sm_cmd cmd[];
+};
+
+struct meson_sm_priv {
+ void *sm_shmem_in;
+ void *sm_shmem_out;
+ const struct meson_sm_data *data;
+};
+
+static unsigned long __meson_sm_call(u32 cmd, const struct pt_regs *args)
+{
+ struct pt_regs r = *args;
+
+ r.regs[0] = cmd;
+ smc_call();
+
+ return r.regs[0];
+};
+
+static u32 meson_sm_get_cmd(const struct meson_sm_data *data,
+ u32 cmd_index)
+{
+ struct meson_sm_cmd cmd;
+
+ if (cmd_index >= MESON_SMC_CMD_COUNT)
+ return 0;
+
+ cmd = data->cmd[cmd_index];
+ return cmd.smc_id;
+}
+
+static int meson_sm_call(struct udevice *dev, u32 cmd_index, s32 *retval,
+struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ u32 cmd, ret;
+
+ cmd = meson_sm_get_cmd(priv->data, cmd_index);
+ if (!cmd)
+ return -ENOENT;
+
+ ret = __meson_sm_call(cmd, args);
+ if (retval)
+ *retval = ret;
+
+ return 0;
+}
+
+static int meson_sm_call_read(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ s32 nbytes;
+ int ret;
+
+ if (!buffer || size > priv->data->shmem_size)
+ return -EINVAL;
+
+ ret = meson_sm_call(dev, cmd_index, , args);
+ if (ret)
+ return ret;
+
+ if (nbytes < 0 || nbytes > size)
+ return -ENOBUFS;
+
+ /* In some cases (for example GET_CHIP_ID command),
+* SMC doesn't return the number of bytes read, even
+* though the bytes were actually read into sm_shmem_out.
+* So this check is needed.
+*/
+ ret = nbytes;
+ if (!nbytes)
+ nbytes = size;
+
+ memcpy(buffer, priv->sm_shmem_out, nbytes);
+
+ return ret;
+}
+
+static int meson_sm_call_write(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ s32 nbytes;
+ int ret;
+
+ if (!buffer || size > priv->data->shmem_size)
+ return -EINVAL;
+
+ memcpy(priv->sm_shmem_in, buffer, size);
+
+ ret = meson_sm_call(dev, cmd_index, , args);
+ if (ret)
+ return ret;
+
+ if (nbytes <= 0 || nbytes > size)
+ return -EIO;
+
+ return nbytes;
+}
+
+static int meson_sm_probe(struct udevice *dev)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ struct pt_regs regs = { 0 };
+
+ priv->data = (struct
[PATCH v3 5/8] sandbox: defconfig: enable CONFIG_SM option
We use this option to test UCLASS_SM. Signed-off-by: Alexey Romanov Reviewed-by: Simon Glass --- configs/sandbox_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index be46cae7aa..0745a4ecca 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -270,6 +270,7 @@ CONFIG_RTC_RV8803=y CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_SANDBOX_SERIAL=y +CONFIG_SM=y CONFIG_SMEM=y CONFIG_SANDBOX_SMEM=y CONFIG_SOUND=y -- 2.25.1
[PATCH v3 4/8] sandbox: add tests for UCLASS_SM
This patchs adds simple tests for Secure Monitor uclass.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
test/dm/Makefile | 1 +
test/dm/sm.c | 65
2 files changed, 66 insertions(+)
create mode 100644 test/dm/sm.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7a79b6e1a2..30550a62ad 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_DM_SPI) += spi.o
obj-$(CONFIG_SPMI) += spmi.o
obj-y += syscon.o
obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o
+obj-$(CONFIG_SM) += sm.o
obj-$(CONFIG_SYSINFO) += sysinfo.o
obj-$(CONFIG_SYSINFO_GPIO) += sysinfo-gpio.o
obj-$(CONFIG_UT_DM) += tag.o
diff --git a/test/dm/sm.c b/test/dm/sm.c
new file mode 100644
index 00..7ebb0c9c85
--- /dev/null
+++ b/test/dm/sm.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int dm_test_sm(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+ struct pt_regs regs;
+ char buffer[128] = { 0 };
+ char test_string[] = "secure-monitor";
+ int ret, val;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_SM,
+ "secure-monitor", ));
+
+ ret = sm_call(dev, SANDBOX_SMC_CMD_COUNT, NULL, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call(dev, SANDBOX_SMC_CMD_COMMON, , );
+ ut_asserteq(ret, 0);
+ ut_asserteq(val, 0);
+
+ ret = sm_call_write(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_COUNT, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, SZ_4K + 1,
+ SANDBOX_SMC_CMD_WRITE_MEM, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_COUNT, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, SZ_4K + 1,
+ SANDBOX_SMC_CMD_READ_MEM, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, test_string, sizeof(test_string),
+ SANDBOX_SMC_CMD_WRITE_MEM, );
+ ut_asserteq(ret, sizeof(test_string));
+
+ ret = sm_call_read(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_READ_MEM, );
+ ut_asserteq(ret, sizeof(buffer));
+
+ ut_asserteq_str(buffer, test_string);
+
+ return 0;
+}
+
+DM_TEST(dm_test_sm, UT_TESTF_SCAN_FDT);
--
2.25.1
[PATCH v3 3/8] sandbox: dts: add meson secure monitor node
We need this to test UCLASS_SM.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
arch/sandbox/dts/test.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..4475aa58a6 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -693,6 +693,10 @@
};
};
};
+
+ sm: secure-monitor {
+ compatible = "sandbox,sm";
+ };
};
fpga {
--
2.25.1
[PATCH v3 2/8] sandbox: add sandbox sm uclass driver
This patch adds sandbox secure monitor driver.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
drivers/sm/Makefile | 1 +
drivers/sm/sandbox-sm.c | 76 +
include/sandbox-sm.h| 18 ++
3 files changed, 95 insertions(+)
create mode 100644 drivers/sm/sandbox-sm.c
create mode 100644 include/sandbox-sm.h
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
index 9f4683ba06..af5f475c2b 100644
--- a/drivers/sm/Makefile
+++ b/drivers/sm/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-y += sm-uclass.o
+obj-$(CONFIG_SANDBOX) += sandbox-sm.o
diff --git a/drivers/sm/sandbox-sm.c b/drivers/sm/sandbox-sm.c
new file mode 100644
index 00..109ddb2af5
--- /dev/null
+++ b/drivers/sm/sandbox-sm.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static u8 test_buffer[SZ_4K];
+
+static int sandbox_sm_call(struct udevice *dev, u32 cmd_index, s32 *smc_ret,
+ struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT)
+ return -EINVAL;
+
+ if (smc_ret)
+ *smc_ret = 0;
+
+ return 0;
+}
+
+static int sandbox_sm_call_read(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT || !buffer)
+ return -EINVAL;
+
+ if (size > sizeof(test_buffer))
+ return -EINVAL;
+
+ memcpy(buffer, test_buffer, size);
+
+ return size;
+}
+
+static int sandbox_sm_call_write(struct udevice *dev, void *buffer, size_t
size,
+u32 cmd_index, struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT || !buffer)
+ return -EINVAL;
+
+ if (size > sizeof(test_buffer))
+ return -EINVAL;
+
+ memcpy(test_buffer, buffer, size);
+
+ return size;
+}
+
+static const struct udevice_id sandbox_sm_ids[] = {
+ {
+ .compatible = "sandbox,sm",
+ },
+ {},
+};
+
+static const struct sm_ops sandbox_sm_ops = {
+ .sm_call = sandbox_sm_call,
+ .sm_call_read = sandbox_sm_call_read,
+ .sm_call_write = sandbox_sm_call_write,
+};
+
+U_BOOT_DRIVER(sm) = {
+ .name = "sm",
+ .id = UCLASS_SM,
+ .of_match = sandbox_sm_ids,
+ .ops = _sm_ops,
+};
diff --git a/include/sandbox-sm.h b/include/sandbox-sm.h
new file mode 100644
index 00..91c30d501d
--- /dev/null
+++ b/include/sandbox-sm.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#ifndef __SANDBOX_SM_H__
+#define __SANDBOX_SM_H__
+
+enum sandbox_smc_cmd {
+ SANDBOX_SMC_CMD_READ_MEM,
+ SANDBOX_SMC_CMD_WRITE_MEM,
+ SANDBOX_SMC_CMD_COMMON,
+ SANDBOX_SMC_CMD_COUNT,
+};
+
+#endif
--
2.25.1
[PATCH v3 0/8] Add SM uclass and Meson SM driver
Hello! At the moment, there is no single general approach to using secure monitor in U-Boot, there is only the smc_call() function, over which everyone builds their own add-ons. This patchset is designed to solve this problem by adding a new uclass - SM_UCLASS. This UCLASS export following generic API: 1. sm_call() - generic SMC call to the secure-monitor 2. sm_call_read() - retrieve data from secure-monitor 3. sm_call_write() - send data to secure-monitor In the future, it is necessary to completely get rid of raw smc_call() calls, replacing them with the use of SM_UCLASS based drivers. V2: - Add SM UCLASS - Add SM sandbox driver - Add test for sandbox driver - Meson Secure Monitor driver now based on SM_UCLASS - Fix include order in arch/arm/mach-meson/sm.c Also, during the discussion in V1 of this patchset, it was discussed to create MESON_SM_UCLASS, but I considered such a uclass to be too arch-specific. That's why I suggest SM_UCLASS, which is not so arch-specific: secure monitor can used for whole ARM devices, not only for Amlogic SoC's. V3: - Fix typos in commit messages - Use uclass_first_device_err() instead of uclass_get_device_by_name() - Return -ENOSYS instead of -EPROTONOSUPPORT if SM_UCLASS option not implemented Alexey Romanov (8): drivers: introduce Secure Monitor uclass sandbox: add sandbox sm uclass driver sandbox: dts: add meson secure monitor node sandbox: add tests for UCLASS_SM sandbox: defconfig: enable CONFIG_SM option drivers: introduce Meson Secure Monitor driver arch: meson: sm: set correct order of the includes arch: meson: use secure monitor driver MAINTAINERS | 1 + arch/arm/mach-meson/Kconfig | 1 + arch/arm/mach-meson/sm.c| 116 +++-- arch/sandbox/dts/test.dts | 4 + configs/sandbox_defconfig | 1 + drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/sm/Kconfig | 9 ++ drivers/sm/Makefile | 5 + drivers/sm/meson-sm.c | 198 drivers/sm/sandbox-sm.c | 76 ++ drivers/sm/sm-uclass.c | 55 ++ include/dm/uclass-id.h | 1 + include/meson/sm.h | 19 include/sandbox-sm.h| 18 include/sm-uclass.h | 72 + include/sm.h| 67 test/dm/Makefile| 1 + test/dm/sm.c| 65 19 files changed, 656 insertions(+), 56 deletions(-) create mode 100644 drivers/sm/Kconfig create mode 100644 drivers/sm/Makefile create mode 100644 drivers/sm/meson-sm.c create mode 100644 drivers/sm/sandbox-sm.c create mode 100644 drivers/sm/sm-uclass.c create mode 100644 include/meson/sm.h create mode 100644 include/sandbox-sm.h create mode 100644 include/sm-uclass.h create mode 100644 include/sm.h create mode 100644 test/dm/sm.c -- 2.25.1
[PATCH v3 1/8] drivers: introduce Secure Monitor uclass
At the moment, we don't have a common API for working with
SM, only the smc_call() function. This approach is not generic
and difficult to configure and maintain.
This patch adds UCLASS_SM with the generic API:
- sm_call()
- sm_call_write()
- sm_call_read()
These functions operate with struct pt_regs, which describes
Secure Monitor arguments.
Signed-off-by: Alexey Romanov
Reviewed-by: Simon Glass
---
drivers/Kconfig| 2 ++
drivers/Makefile | 1 +
drivers/sm/Kconfig | 2 ++
drivers/sm/Makefile| 3 ++
drivers/sm/sm-uclass.c | 55
include/dm/uclass-id.h | 1 +
include/sm-uclass.h| 72 ++
include/sm.h | 67 +++
8 files changed, 203 insertions(+)
create mode 100644 drivers/sm/Kconfig
create mode 100644 drivers/sm/Makefile
create mode 100644 drivers/sm/sm-uclass.c
create mode 100644 include/sm-uclass.h
create mode 100644 include/sm.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 75ac149d31..72e6405322 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -112,6 +112,8 @@ source "drivers/scsi/Kconfig"
source "drivers/serial/Kconfig"
+source "drivers/sm/Kconfig"
+
source "drivers/smem/Kconfig"
source "drivers/sound/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 6f1de58e00..b7bd3633b1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DM_RNG) += rng/
endif
obj-y += soc/
+obj-y += sm/
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
new file mode 100644
index 00..6cc6d55578
--- /dev/null
+++ b/drivers/sm/Kconfig
@@ -0,0 +1,2 @@
+config SM
+ bool "Enable Secure Monitor driver support"
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
new file mode 100644
index 00..9f4683ba06
--- /dev/null
+++ b/drivers/sm/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += sm-uclass.o
diff --git a/drivers/sm/sm-uclass.c b/drivers/sm/sm-uclass.c
new file mode 100644
index 00..6a8b702629
--- /dev/null
+++ b/drivers/sm/sm-uclass.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+
+static const struct sm_ops *get_sm_ops(struct udevice *dev)
+{
+ return (const struct sm_ops *)dev->driver->ops;
+}
+
+int sm_call(struct udevice *dev, u32 cmd, s32 *ret, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call)
+ return ops->sm_call(dev, cmd, ret, args);
+
+ return -ENOSYS;
+}
+
+int sm_call_read(struct udevice *dev, void *buffer, size_t size,
+u32 cmd, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call_read)
+ return ops->sm_call_read(dev, buffer, size, cmd,
+args);
+
+ return -ENOSYS;
+}
+
+int sm_call_write(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call_write)
+ return ops->sm_call_write(dev, buffer, size, cmd,
+ args);
+
+ return -ENOSYS;
+}
+
+UCLASS_DRIVER(sm) = {
+ .name = "sm",
+ .id = UCLASS_SM,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 376f741cc2..545c9352a8 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -80,6 +80,7 @@ enum uclass_id {
UCLASS_MDIO,/* MDIO bus */
UCLASS_MDIO_MUX,/* MDIO MUX/switch */
UCLASS_MEMORY, /* Memory Controller device */
+ UCLASS_SM, /* Secure Monitor driver */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/sm-uclass.h b/include/sm-uclass.h
new file mode 100644
index 00..c114484044
--- /dev/null
+++ b/include/sm-uclass.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#ifndef __SM_UCLASS_H__
+#define __SM_UCLASS_H__
+
+#include
+#include
+
+struct udevice;
+
+/**
+ * struct sm_ops - The functions that a SM driver must implement.
+ *
+ * @sm_call: Request a secure monitor call with specified command.
+ *
+ * @sm_call_read: Request a secure monitor call and retrieve data
+ * from secure-monitor (depends on specified command).
+ *
+ * @sm_call_write: Request a secure monitor call and send data
+ * to secure-monitor (depends on specified command).
+ *
+ * The individual methods are described more fully below.
+ */
+struct sm_ops {
+ /**
+* sm_call - generic SMC call to the
[PATCH v7 2/2] serial: zynqmp: Fetch baudrate from dtb and update
From: Algapally Santosh Sagar
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
---
doc/README.serial_dt_baud | 41
drivers/core/ofnode.c | 18 ++
drivers/serial/Kconfig | 9 +++
drivers/serial/serial-uclass.c | 43 ++
include/dm/ofnode.h| 14 +--
include/env_default.h | 6 -
include/serial.h | 15
7 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 doc/README.serial_dt_baud
diff --git a/doc/README.serial_dt_baud b/doc/README.serial_dt_baud
new file mode 100644
index 00..f8768d0e1b
--- /dev/null
+++ b/doc/README.serial_dt_baud
@@ -0,0 +1,41 @@
+Fetch serial baudrate from DT
+-
+
+To support fetching of baudrate from DT, the following is done:-
+
+The baudrate configured in Kconfig symbol CONFIG_BAUDRATE is taken by default
by serial.
+If change of baudrate is required then the Kconfig symbol CONFIG_BAUDRATE
needs to
+changed and U-Boot recompilation is required or the U-Boot environment needs
to be updated.
+
+To avoid this, add support to fetch the baudrate directly from the device tree
file and
+update the environment.
+
+The default environment stores the default baudrate value. When default
baudrate and dtb
+baudrate are not same glitches are seen on the serial.
+So, the environment also needs to be updated with the dtb baudrate to avoid
the glitches on
+the serial which is enabled by OF_SERIAL_BAUD.
+
+The Kconfig SPL_ENV_SUPPORT needs to be enabled to allow patching in SPL.
+
+The Kconfig DEFAULT_ENV_IS_RW which is enabled by OF_SERIAL_BAUD with making
the environment
+writable.
+
+The ofnode_read_baud() function parses and fetches the baudrate value from the
DT. This value
+is validated and updated to baudrate during serial init. Padding is added at
the end of the
+default environment and the dt baudrate is updated with the latest value.
+
+Example:-
+
+The serial port options are of the form "pnf", where "" is the baud
rate, "p" is parity ("n", "o", or "e"),
+"n" is number of bits, and "f" is flow control ("r" for RTS or omit it).
Default is "115200n8".
+
+chosen {
+ bootargs = "earlycon console=ttyPS0,115200 clk_ignore_unused
root=/dev/ram0 rw init_fatal_sh=1";
+ stdout-path = "serial0:115200n8";
+ };
+
+From the chosen node, stdout-path property is obtained as string.
+
+ stdout-path = "serial0:115200n8";
+
+The string is parsed to get the baudrate 115200. This string is converted to
integer and updated to the environment.
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af..42f51ca93c 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -895,6 +895,24 @@ ofnode ofnode_get_chosen_node(const char *name)
return ofnode_path(prop);
}
+int ofnode_read_baud(void)
+{
+ const char *str, *p;
+ u32 baud;
+
+ str = ofnode_read_chosen_string("stdout-path");
+ if (!str)
+ return -EINVAL;
+
+ /* Parse string serial0:115200n8 */
+ p = strchr(str, ':');
+ if (!p)
+ return -EINVAL;
+
+ baud = dectoul(p + 1, NULL);
+ return baud;
+}
+
const void *ofnode_read_aliases_prop(const char *propname, int *sizep)
{
ofnode node;
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 4d27034c3f..7fdf600dc5 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -24,6 +24,15 @@ config BAUDRATE
in the SPL stage (most drivers) or for choosing a default baudrate
in the absence of an environment setting (serial_mxc.c).
+config OF_SERIAL_BAUD
+ bool "Fetch serial baudrate from device tree"
+ depends on DM_SERIAL && SPL_ENV_SUPPORT
+ select DEFAULT_ENV_IS_RW
+ help
+ Select this to enable fetching and setting of the baudrate
+ configured in the DT. Replace the default baudrate with the DT
+ baudrate and also set it to the environment.
+
config DEFAULT_ENV_IS_RW
bool "Make default environment as
[PATCH v7 1/2] configs: Add support in Kconfig and convert for armada boards
From: Algapally Santosh Sagar
Move the DEFAULT_ENV_IS_RW to Kconfig for easier configuration.
Hence, add the CONFIG_DEFAULT_ENV_IS_RW config to the defconfig files
to allow enabling them for armada boards.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
Reviewed-by: Simon Glass
---
configs/eDPU_defconfig | 1 +
configs/mvebu_db-88f3720_defconfig | 1 +
configs/mvebu_espressobin-88f3720_defconfig | 1 +
configs/uDPU_defconfig | 1 +
drivers/serial/Kconfig | 6 ++
include/configs/mvebu_armada-37xx.h | 1 -
include/env_default.h | 2 +-
include/env_internal.h | 2 +-
8 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/configs/eDPU_defconfig b/configs/eDPU_defconfig
index 77ea2b2eec..61fb9bd2a5 100644
--- a/configs/eDPU_defconfig
+++ b/configs/eDPU_defconfig
@@ -21,6 +21,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/configs/mvebu_db-88f3720_defconfig
b/configs/mvebu_db-88f3720_defconfig
index 829567014f..e6fb80167a 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -22,6 +22,7 @@ CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/configs/mvebu_espressobin-88f3720_defconfig
b/configs/mvebu_espressobin-88f3720_defconfig
index fc394a7e9d..64ee99d64b 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -24,6 +24,7 @@ CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_BOARD_LATE_INIT=y
diff --git a/configs/uDPU_defconfig b/configs/uDPU_defconfig
index fa1989518b..4d3d53ac7e 100644
--- a/configs/uDPU_defconfig
+++ b/configs/uDPU_defconfig
@@ -21,6 +21,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DEFAULT_ENV_IS_RW=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MAXARGS=32
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 8c54bc9c47..4d27034c3f 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -24,6 +24,12 @@ config BAUDRATE
in the SPL stage (most drivers) or for choosing a default baudrate
in the absence of an environment setting (serial_mxc.c).
+config DEFAULT_ENV_IS_RW
+ bool "Make default environment as writable"
+ help
+ Select this to enable to make default environment writable. This
+ allows modifying the default environment.
+
config REQUIRE_SERIAL_CONSOLE
bool "Require a serial port for console"
# Running without a serial console is not supported by the
diff --git a/include/configs/mvebu_armada-37xx.h
b/include/configs/mvebu_armada-37xx.h
index 76e148f55e..18b55be0d8 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -30,7 +30,6 @@
/*
* Environment
*/
-#define DEFAULT_ENV_IS_RW /* required for configuring default
fdtfile= */
#ifdef CONFIG_MMC
#define BOOT_TARGET_DEVICES_MMC(func, i) func(MMC, mmc, i)
diff --git a/include/env_default.h b/include/env_default.h
index b16c22d5a2..227cad7c34 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -21,7 +21,7 @@ env_t embedded_environment __UBOOT_ENV_SECTION__(environment)
= {
{
#elif defined(DEFAULT_ENV_INSTANCE_STATIC)
static char default_environment[] = {
-#elif defined(DEFAULT_ENV_IS_RW)
+#elif defined(CONFIG_DEFAULT_ENV_IS_RW)
char default_environment[] = {
#else
const char default_environment[] = {
diff --git a/include/env_internal.h b/include/env_internal.h
index 6a69494646..fcb464263f 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -89,7 +89,7 @@ typedef struct environment_s {
extern env_t embedded_environment;
#endif /* ENV_IS_EMBEDDED */
-#ifdef DEFAULT_ENV_IS_RW
+#ifdef CONFIG_DEFAULT_ENV_IS_RW
extern char default_environment[];
#else
extern const char default_environment[];
--
2.17.1
[PATCH v7 0/2] Add support to fetch baudrate from dtb
In this patch series - Add support in Kconfig and convert for armada boards - Fetch baudrate from the dtb and update Changes in v7: - Updated the commit message. Changes in v6: - Changed Kconfig OF_SERIAL_DT_BAUD to OF_SERIAL_BAUD. - Added IS_ENABLED() in place of #ifdef CONFIG_OF_SERIAL_AUD Changes in v5: - Adding DEFAULT_ENV_IS_RW Kconfig in missing files - Updating DEFAULT_ENV_IS_RW to CONFIG_DEFAULT_ENV_IS_RW Changes in v4: - Moved SERIAL_DT_BAUD to another patch - Added doc file for fetching serial baudrate from DT. - Changed Kconfig SERIAL_DT_BAUD to OF_SERIAL_DT_BAUD - Added function docs wherever required. - Moved changes from fdtdec api to ofnode - Changed serial_get_valid_baudrate to check_valid_baudrate - Added function fetch_baud_from_dtb to fetch baud from DT - Used dectoul() for parsing baudrate Changes in v3: - Add SERIAL_DT_BAUD to Kconfig - Moved DEFAULT_ENV_IS_RW to Kconfig also updated armada files - Moved filler changes from zynqmp.h to generic file env_default.h - Removed ENV_RW_FILLER and added padding in the generic file env_default.h. - Print baudrate parameter properly when SERIAL_DT is enabled. Changes in v2: - Changed to #ifdef from #if CONFIG_IS_ENABLED to enable patching in spl. - Added SPL_ENV_SUPPORT dependency in SERIAL_DT_BAUD to allow SPL compilation. - Moved DEFAULT_ENV_IS_RW to Kconfig also updated armada files - Moved ENV_RW_FILLER to generic file env_default.h. - Increased the ENV_RW_FILLER padding to support 800 baud. Algapally Santosh Sagar (2): configs: Add support in Kconfig and convert for armada boards serial: zynqmp: Fetch baudrate from dtb and update configs/eDPU_defconfig | 1 + configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_espressobin-88f3720_defconfig | 1 + configs/uDPU_defconfig | 1 + doc/README.serial_dt_baud | 41 drivers/core/ofnode.c | 18 + drivers/serial/Kconfig | 15 +++ drivers/serial/serial-uclass.c | 43 + include/configs/mvebu_armada-37xx.h | 1 - include/dm/ofnode.h | 14 ++- include/env_default.h | 8 +++- include/env_internal.h | 2 +- include/serial.h| 15 +++ 13 files changed, 155 insertions(+), 6 deletions(-) create mode 100644 doc/README.serial_dt_baud -- 2.17.1
[PATCH v2 00/32] spl: Preparation for Universal Payload
This series tidies up SPL a little and adds some core ofnode functions needed to support Universal Payload. It also includes a few minor fix-ups for sandbox. For SPL the changes include CONFIG naming, removing various #ifdefs and tidying up the FIT code. One notable piece of the ofnode improvements is support for flattening a livetree. This should be useful in future as we move FDT fixups to use the ofnode API. Changes in v2: - Rename based on Tom's feedback - Improve readability by moving the size part to the header file - Explicitly copy two maintainers as it seems only Mario was auto-cc'd - Change the approach to use the header file - Use the same condition for both pieces to avoid possible problems - No changes as it still seems unclear what should be done Michal Simek (1): dm: core: support reading a single indexed u64 value Simon Glass (31): spl: Use CONFIG_SPL... instead of CONFIG_..._SPL_... spl: Rename SYS_SPL_ARGS_ADDR to SPL_PAYLOAD_ARGS_ADDR spl: Avoid #ifdef with CONFIG_SPL_SYS_MALLOC spl: mx6: powerpc: Drop the condition on timer_init() spl: Drop #ifdefs for BOARD_INIT and watchdog spl: Avoid #ifdef with CONFIG_SPL_PAYLOAD_ARGS_ADDR spl: Drop the switch() statement for OS selection spl: Avoid an #ifdef when printing gd->malloc_ptr spl: Remove #ifdefs with BOOTSTAGE spl: Rename spl_load_fit_image() to load_simple_fit() spl: Move the full FIT code to spl_fit.c spl: Use the correct FIT_..._PROP constants spl: Move bloblist writing until the image is known dm: core: Reverse the argument order in ofnode_copy_props() dm: core: Ensure we run flattree tests on ofnode dm: core: Tidy up comments in the ofnode tests dm: core: Add a function to create an empty tree dm: core: Add a way to copy a node dm: core: Add a way to delete a node dm: core: Add a way to convert a devicetree to a dtb dm: core: Support writing a boolean dm: core: Support writing a 64-bit value dm: core: Add tests for oftree_path() sandbox: Move reading the RAM buffer into a better place sandbox: Init the EC properly even if no state file is available sandbox: Only read the state if we have a state file sandbox: Move the bloblist down a little in memory bloblist: Support initing from multiple places fdt: Allow the devicetree to come from a bloblist command: Include a required header in command.h pci: serial: Support reading PCI-register size with base Kconfig | 2 +- README| 2 +- arch/arm/cpu/armv7/ls102xa/fdt.c | 2 +- .../armv8/fsl-layerscape/doc/README.falcon| 2 +- arch/sandbox/cpu/start.c | 27 +- arch/sandbox/cpu/state.c | 2 + arch/sandbox/dts/test.dts | 7 +- boot/vbe_request.c| 2 +- boot/vbe_simple_os.c | 2 +- common/Kconfig| 2 +- common/bloblist.c | 15 +- common/board_f.c | 4 +- common/spl/Kconfig| 16 +- common/spl/Kconfig.nxp| 2 +- common/spl/spl.c | 222 --- common/spl/spl_ext.c | 4 +- common/spl/spl_fat.c | 4 +- common/spl/spl_fit.c | 127 +++-- common/spl/spl_mmc.c | 2 +- common/spl/spl_nand.c | 10 +- common/spl/spl_nor.c | 8 +- common/spl/spl_spi.c | 2 +- common/spl/spl_ubi.c | 2 +- common/spl/spl_xip.c | 2 +- configs/am335x_baltos_defconfig | 4 +- configs/am335x_boneblack_vboot_defconfig | 4 +- configs/am335x_evm_defconfig | 4 +- configs/am335x_evm_spiboot_defconfig | 4 +- configs/am335x_guardian_defconfig | 4 +- configs/am335x_hs_evm_defconfig | 4 +- configs/am335x_hs_evm_uart_defconfig | 4 +- configs/am335x_igep003x_defconfig | 4 +- configs/am335x_pdu001_defconfig | 4 +- configs/am335x_shc_defconfig | 4 +- configs/am335x_shc_ict_defconfig | 4 +- configs/am335x_shc_netboot_defconfig | 4 +- configs/am335x_shc_sdboot_defconfig | 4 +- configs/am335x_sl50_defconfig | 4 +- configs/am3517_evm_defconfig | 6 +- configs/am43xx_evm_defconfig | 4 +- configs/am43xx_evm_rtconly_defconfig | 4 +- configs/am43xx_evm_usbhost_boot_defconfig | 4 +- configs/am43xx_hs_evm_defconfig | 4 +- configs/am57xx_evm_defconfig | 4 +- configs/am57xx_hs_evm_defconfig | 4 +-
Re: [PATCH] arm64: versal: Add SelectMAP boot mode identification
On 9/19/23 14:47, Polak, Leszek wrote:
Add missing SelectMAP bootmode for proper identification during boot.
The SelectMAP configuration interface provides an 8-bit, 16-bit or
32-bit bidirectional data bus interface to the Versal FPGA
configuration logic that can be used for both configuration and
readback.
A connected microcontoller to the SelectMAP interface can load boot
image with bitstream, TF-A (ARM Trusted Firmware) and U-Boot.
This commit adds the missing identification of the SelectMAP mode.
Signed-off-by: Leszek Polak
Cc: Michal Simek
Cc: Stefan Roese
---
arch/arm/mach-versal-net/include/mach/hardware.h | 1 +
arch/arm/mach-versal/include/mach/hardware.h | 1 +
board/xilinx/versal-net/board.c | 4
board/xilinx/versal/board.c | 5 +
4 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 9bddb8b00723..767cdd368682 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -66,6 +66,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/arch/arm/mach-versal/include/mach/hardware.h
b/arch/arm/mach-versal/include/mach/hardware.h
index 000af974e867..9d1c2f0dcfc1 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -82,6 +82,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index f0d2224b332e..992e0df73b30 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -287,6 +287,10 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ mode = "selectmap";
We are not defining distro boot for selectmap that's why boot_targets don't need
to be extended. That's why please remove this line.
+ break;
default:
mode = "";
printf("Invalid Boot Mode:0x%x\n", bootmode);
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 60bf37d3c90f..b619dbc73c80 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -213,6 +213,10 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ mode = "selectmap";
The same here.
+ break;
default:
mode = "";
printf("Invalid Boot Mode:0x%x\n", bootmode);
@@ -298,6 +302,7 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
case JTAG_MODE:
+ case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
--
2.42.0
The rest looks good to me.
Thanks,
Michal
Re: [PATCH v2 0/2] Fix issues for small sized data reads
On 9/15/23 05:17, Venkatesh Yadav Abbarapu wrote: Change flush cache to invalidate cache and also fix cache related issues are seen with small sized data reads. Due to this, proper data is not read. Also some times sf probe fails randomly. Ashok Reddy Soma (1): spi: zynqmp_qspi: Change flush cache to invalidate cache Venkatesh Yadav Abbarapu (1): spi: zynqmp_qspi: Workaround for small data cache issue drivers/spi/zynqmp_gqspi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Applied. M
Re: [PATCH] net: phy: xilinx-gmii2rgmii: Removed hardcoded phy address 0 for bridge
On 9/15/23 06:50, Tejas Bhumkar wrote:
Current code expects bridge phy address at 0 which is not correct
expectation because bridge phy address is configurable.
That's why update the code to read reg property to figure it out
where bridge is and use it in phy creation code.
Signed-off-by: Michal Simek
Signed-off-by: Tejas Bhumkar
---
drivers/net/phy/phy.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ae21acb059..d64a83b83d 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -838,7 +838,10 @@ static struct phy_device *phy_connect_gmii2rgmii(struct
mii_dev *bus,
ofnode_for_each_subnode(node, dev_ofnode(dev)) {
node = ofnode_by_compatible(node, "xlnx,gmii-to-rgmii-1.0");
if (ofnode_valid(node)) {
- phydev = phy_device_create(bus, 0,
+ int gmiirgmii_phyaddr;
+
+ gmiirgmii_phyaddr = ofnode_read_u32_default(node,
"reg", 0);
+ phydev = phy_device_create(bus, gmiirgmii_phyaddr,
PHY_GMII2RGMII_ID, false);
if (phydev)
phydev->node = node;
Applied.
M
Re: [PATCH v2 0/3] trace: Fix flyrecord alignment issue
On 9/15/23 14:12, Michal Simek wrote: Hi, sandbox is getting bigger and bigger and I have reached the case that adding some more functions ends up in CI loop failure. After some investigation I found that flyrecord header have incorrect information about data offset which is caused by incorrect alignment calculation. That's why this series is fixing alignment calculation. I have done it via 3 patches where the first two are just preparing code for actual fixup. Thanks, Michal Changes in v2: - s/start_addr/start_ofs/g' Michal Simek (3): trace: Use 64bit variable for start and len trace: Move trace_clocks description above record offset calculation trace: Fix alignment logic in flyrecord header tools/proftool.c | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) Applied. M
Re: [PATCH v2] cmd: sf: Fix the flash_is_unlocked api size parameter
On 9/20/23 04:54, Venkatesh Yadav Abbarapu wrote:
When flash erase is called with size parameter, code is checking
if sectors are locked or not. But for checking, the whole device
length minus offset is used instead of actual size which should
be erased. That's why when only some sectors are locked it is
not possible to erase unlocked sectors.
The length is calculated as "length = max_chipsize - offset",
flash_is_unlocked() api is getting updated with length which is
incorrect. Fix this flash_is_unlocked() api by passing the size
parameter.
ZynqMP> sf erase 0 10
len=0x800 which is flash size
size=0x10
We need to update the size in the flash_is_unlocked() api and not
the length.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Updated the commit description.
---
cmd/sf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/sf.c b/cmd/sf.c
index 55bef2f769..977ffcb63c 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -366,7 +366,7 @@ static int do_spi_flash_erase(int argc, char *const argv[])
}
if (flash->flash_is_unlocked &&
- !flash->flash_is_unlocked(flash, offset, len)) {
+ !flash->flash_is_unlocked(flash, offset, size)) {
printf("ERROR: flash area is locked\n");
return CMD_RET_FAILURE;
}
Applied.
M
[PATCH v6 7/7] board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File.
Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due to the previous MAINTAINER not being associated with TI. Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- board/ti/j721s2/MAINTAINERS | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/board/ti/j721s2/MAINTAINERS b/board/ti/j721s2/MAINTAINERS index 323bd2353a7e..08c8d110ac0a 100644 --- a/board/ti/j721s2/MAINTAINERS +++ b/board/ti/j721s2/MAINTAINERS @@ -1,16 +1,23 @@ J721S2 BOARD -M: Aswath Govindraju +M: Manorit Chawdhry S: Maintained F: board/ti/j721s2 +F: arch/arm/mach-k3/j721s2 +F: doc/board/ti/j721s2_evm.rst F: include/configs/j721s2_evm.h F: configs/j721s2_evm_r5_defconfig F: configs/j721s2_evm_a72_defconfig F: arch/arm/dts/k3-j721s2.dtsi F: arch/arm/dts/k3-j721s2-main.dtsi F: arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi +F: arch/arm/dts/k3-j721s2-thermal.dtsi F: arch/arm/dts/k3-j721s2-som-p0.dtsi F: arch/arm/dts/k3-j721s2-common-proc-board.dts F: arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi -F: arch/arm/dts//k3-j721s2-r5-common-proc-board.dts +F: arch/arm/dts/k3-j721s2-r5-common-proc-board.dts F: arch/arm/dts/k3-j721s2-ddr.dtsi F: arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi +F: arch/arm/dts/k3-am68-sk-som.dtsi +F: arch/arm/dts/k3-am68-sk-base-board.dts +F: arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi +F: arch/arm/dts/k3-am68-sk-r5-base-board.dts -- 2.41.0
[PATCH v6 6/7] docs: board: ti: Add j721s2_evm documentation
Add the documentation for J721S2-EVM and SK-AM68 TRM for J721S2/AM68: https://www.ti.com/lit/pdf/spruj28 Product Page for J721S2: https://www.ti.com/tool/J721S2XSOMXEVM Product Page for AM68: https://www.ti.com/tool/SK-AM68 Reviewed-by: Neha Malcom Francis Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- doc/board/ti/j721s2_evm.rst | 341 doc/board/ti/k3.rst | 1 + 2 files changed, 342 insertions(+) diff --git a/doc/board/ti/j721s2_evm.rst b/doc/board/ti/j721s2_evm.rst new file mode 100644 index ..fec2acabe845 --- /dev/null +++ b/doc/board/ti/j721s2_evm.rst @@ -0,0 +1,341 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Manorit Chawdhry + +J721S2 and AM68 Platforms += + +Introduction: +- +The J721S2 family of SoCs are part of K3 Multicore SoC architecture platform +targeting automotive applications. They are designed as a low power, high +performance and highly integrated device architecture, adding significant +enhancement on processing power, graphics capability, video and imaging +processing, virtualization and coherent memory support. + +The AM68 Starter Kit/Evaluation Module (EVM) is based on the J721S2 family +of SoCs. They are designed for machine vision, traffic monitoring, retail +automation, and factory automation. + +The device is partitioned into three functional domains, each containing +specific processing cores and peripherals: + +1. Wake-up (WKUP) domain: +* ARM Cortex-M4F processor, runs TI Foundational Security (TIFS) + +2. Microcontroller (MCU) domain: +* Dual core ARM Cortex-R5F processor, runs device management + and SoC early boot + +3. MAIN domain: +* Dual core 64-bit ARM Cortex-A72, runs HLOS + +More info can be found in TRM: https://www.ti.com/lit/pdf/spruj28 + +Platform information: + +* https://www.ti.com/tool/J721S2XSOMXEVM +* https://www.ti.com/tool/SK-AM68 + +Boot Flow: +-- +Below is the pictorial representation of boot flow: + +.. image:: img/boot_diagram_k3_current.svg + +- On this platform, "TI Foundational Security" (TIFS) functions as the + security enclave master while "Device Manager" (DM), also known as the + "TISCI server" in TI terminology, offers all the essential services. + +- As illustrated in the diagram above, R5 SPL manages power and clock + services independently before handing over control to "DM". The A72 or + the C7x (Aux core) software components request TIFS/DM to handle + security or device management services. + +Sources: + + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_boot_sources +:end-before: .. k3_rst_include_end_boot_sources + +Build procedure: + +0. Setup the environment variables: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_desc +:end-before: .. k3_rst_include_end_common_env_vars_desc + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_board_env_vars_desc +:end-before: .. k3_rst_include_end_board_env_vars_desc + +Set the variables corresponding to this platform: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_defn +:end-before: .. k3_rst_include_end_common_env_vars_defn +.. code-block:: bash + + $ export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig + $ export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig + $ export TFA_BOARD=generic + $ export TFA_EXTRA_ARGS="K3_USART=0x8" + $ # The following is not a typo, j784s4 is the OP-TEE platform for j721s2 + $ export OPTEE_PLATFORM=k3-j784s4 + $ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8" + +.. j721s2_evm_rst_include_start_build_steps + +1. Trusted Firmware-A: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_tfa +:end-before: .. k3_rst_include_end_build_steps_tfa + + +2. OP-TEE: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_optee +:end-before: .. k3_rst_include_end_build_steps_optee + +3. U-Boot: + +.. _j721s2_evm_rst_u_boot_r5: + +* 3.1 R5: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_spl_r5 +:end-before: .. k3_rst_include_end_build_steps_spl_r5 + +.. _j721s2_evm_rst_u_boot_a72: + +* 3.2 A72: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_uboot +:end-before: .. k3_rst_include_end_build_steps_uboot +.. j721s2_evm_rst_include_end_build_steps + +Target Images +-- +In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC +variant (GP, HS-FS, HS-SE) requires a different source for these files. + + - GP + +* tiboot3-j721s2-gp-evm.bin from :ref:`step 3.1 ` +* tispl.bin_unsigned, u-boot.img_unsigned from :ref:`step 3.2 ` + + - HS-FS + +* tiboot3-j721s2-hs-fs-evm.bin from :ref:`step 3.1 ` +* tispl.bin, u-boot.img from :ref:`step 3.2 ` + + - HS-SE + +* tiboot3-j721s2-hs-evm.bin from :ref:`step
[PATCH v6 5/7] arm: dts: k3-am68: Sync from Linux tag v6.6-rc1
The following commit syncs the device tree from Linux tag
v6.6-rc1 to U-boot and fixes the following to be compatible with
the future syncs -
- Include k3-am68-sk-base-board.dts file
Remove the duplicated pinmuxes from r5 and -u-boot.dtsi files and
include k3-am68-sk-base-board.dts for Linux fixes to propagate
to U-boot.
- Fixing the mcu_timer0
Remove timer0 and use the mcu_timer0 defined in mcu-wakeup.dtsi
- Fixing secure proxy nodes
Linux DT now have these nodes defined so remove them and rename to
use the Linux DT ones.
- Remove cpsw node
The compatible is now fixed and the node is not required in
-u-boot specifically
- Remove aliases and chosen node
Use these from Linux and don't override when not required.
- Remove /delete-property/ from sdhci nodes
We have the necessary clock and dev data so remove these.
- Remove dummy_clocks and fs_loader0
These weren't being used anywhere so remove it.
- Remove mcu_ringacc override
All these have been put in a single commit to not break the
bisectability.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 75 ++--
arch/arm/dts/k3-am68-sk-base-board.dts | 524 +
arch/arm/dts/k3-am68-sk-r5-base-board.dts | 151 +--
arch/arm/dts/k3-am68-sk-som.dtsi | 112 +-
4 files changed, 431 insertions(+), 431 deletions(-)
diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
index 79faa1b5737d..5dc580ee6e2f 100644
--- a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
@@ -1,29 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j721s2-binman.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- serial0 = _uart0;
- serial1 = _uart0;
- serial2 = _uart8;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
- ethernet0 = _port1;
- mmc1 = _sdhci1;
- };
-};
-
_i2c0 {
bootph-pre-ram;
};
@@ -39,14 +20,6 @@
_mcu_wakeup {
bootph-pre-ram;
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
-
chipid@4314 {
bootph-pre-ram;
};
@@ -57,12 +30,6 @@
};
_ringacc {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
bootph-pre-ram;
};
@@ -102,10 +69,26 @@
bootph-pre-ram;
};
+_usbss0_pins_default {
+ bootph-pre-ram;
+};
+
_pmx0 {
bootph-pre-ram;
};
+_pmx1 {
+ bootph-pre-ram;
+};
+
+_pmx2 {
+ bootph-pre-ram;
+};
+
+_pmx3 {
+ bootph-pre-ram;
+};
+
_pds {
bootph-pre-ram;
};
@@ -130,23 +113,23 @@
bootph-pre-ram;
};
-_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x8>;
- reg-names = "cpsw_nuss", "mac_efuse";
- /delete-property/ ranges;
+_sdhci1 {
+ bootph-pre-ram;
+};
- cpsw-phy-sel@40f04040 {
- compatible = "ti,am654-cpsw-phy-sel";
- reg= <0x0 0x40f04040 0x0 0x4>;
- reg-names = "gmii-sel";
- };
+ {
+ status = "disabled";
};
-_sdhci0 {
+ {
status = "disabled";
};
-_sdhci1 {
+ {
+ bootph-pre-ram;
+};
+
+ {
+ dr_mode = "peripheral";
bootph-pre-ram;
};
diff --git a/arch/arm/dts/k3-am68-sk-base-board.dts
b/arch/arm/dts/k3-am68-sk-base-board.dts
index 8fc03324ab8a..5df5946687b3 100644
--- a/arch/arm/dts/k3-am68-sk-base-board.dts
+++ b/arch/arm/dts/k3-am68-sk-base-board.dts
@@ -1,8 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
*
- * Base Board: **Yet to Add**
+ * Base Board: https://www.ti.com/lit/zip/SPRR463
*/
/dts-v1/;
@@ -12,21 +12,28 @@
#include
#include
+#include "k3-serdes.h"
+
/ {
compatible = "ti,am68-sk", "ti,j721s2";
model = "Texas Instruments AM68 SK";
chosen {
stdout-path = "serial2:115200n8";
- bootargs =
[PATCH v6 4/7] arm: dts: k3-j721s2: Sync from Linux tag v6.6-rc1
The following commit syncs the device tree from Linux tag
v6.6-rc1 to U-boot and fixes the following to be compatible with
the future syncs -
- Include k3-j721s2-common-proc-board.dts file
Remove the duplicated pinmuxes from r5 and -u-boot.dtsi files and
include k3-j721s2-common-proc-board.dts for Linux fixes to propagate
to U-boot.
- Fixing the mcu_timer0
Remove timer0 and use the mcu_timer0 defined in mcu-wakeup.dtsi
- Fixing secure proxy nodes
Linux DT now have these nodes defined so remove them and rename to
use the Linux DT ones.
- Remove cpsw node
The compatible is now fixed and the node is not required in
-u-boot specifically
- Remove aliases and chosen node
Use these from Linux and don't override when not required.
- Remove /delete-property/ from sdhci nodes
We have the necessary clock and dev data so remove these.
- Remove dummy_clocks and fs_loader0
These weren't being used anywhere so remove it.
- Remove mcu_ringacc override
All these have been put in a single commit to not break the
bisectability.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
.../dts/k3-j721s2-common-proc-board-u-boot.dtsi| 66 +-
arch/arm/dts/k3-j721s2-common-proc-board.dts | 376 ++
arch/arm/dts/k3-j721s2-main.dtsi | 777 -
arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 374 +-
arch/arm/dts/k3-j721s2-r5-common-proc-board.dts| 158 +
arch/arm/dts/k3-j721s2-som-p0.dtsi | 172 ++---
arch/arm/dts/k3-j721s2-thermal.dtsi| 101 +++
arch/arm/dts/k3-j721s2.dtsi| 12 +-
arch/arm/dts/k3-serdes.h | 204 ++
9 files changed, 1794 insertions(+), 446 deletions(-)
diff --git a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
index f940ffee8787..a49561bc364b 100644
--- a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
@@ -1,28 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2021-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j721s2-binman.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- serial0 = _uart0;
- serial1 = _uart0;
- serial2 = _uart8;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
- ethernet0 = _port1;
- };
-};
-
_i2c0 {
bootph-pre-ram;
};
@@ -38,14 +20,6 @@
_mcu_wakeup {
bootph-pre-ram;
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
-
chipid@4314 {
bootph-pre-ram;
};
@@ -56,12 +30,6 @@
};
_ringacc {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
bootph-pre-ram;
};
@@ -101,6 +69,10 @@
bootph-pre-ram;
};
+_usbss0_pins_default {
+ bootph-pre-ram;
+};
+
_pmx0 {
bootph-pre-ram;
};
@@ -129,23 +101,27 @@
bootph-pre-ram;
};
-_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x8>;
- reg-names = "cpsw_nuss", "mac_efuse";
- /delete-property/ ranges;
+_sdhci0 {
+ bootph-pre-ram;
+};
- cpsw-phy-sel@40f04040 {
- compatible = "ti,am654-cpsw-phy-sel";
- reg= <0x0 0x40f04040 0x0 0x4>;
- reg-names = "gmii-sel";
- };
+_sdhci1 {
+ bootph-pre-ram;
};
-_sdhci0 {
+ {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
bootph-pre-ram;
};
-_sdhci1 {
+ {
+ dr_mode = "peripheral";
bootph-pre-ram;
};
diff --git a/arch/arm/dts/k3-j721s2-common-proc-board.dts
b/arch/arm/dts/k3-j721s2-common-proc-board.dts
index 3bba6473a3b6..c6b85bbf9a17 100644
--- a/arch/arm/dts/k3-j721s2-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721s2-common-proc-board.dts
@@ -2,13 +2,17 @@
/*
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
*
- * Link to Common Processor Board: https://www.ti.com/lit/zip/sprr439
+ * Common Processor Board: https://www.ti.com/tool/J721EXCPXEVM
*/
/dts-v1/;
#include "k3-j721s2-som-p0.dtsi"
#include
+#include
+#include
+
+#include
[PATCH v6 3/7] arm: mach-k3: j721s2: Add mcu_timer0 id to the dev list
mcu_timer0 is used by u-boot as the tick-timer. Add it to the soc
devices lsit so it an be enabled via the k3 power controller.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
arch/arm/mach-k3/j721s2/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j721s2/dev-data.c
b/arch/arm/mach-k3/j721s2/dev-data.c
index 8c999a3c5a8b..df70c5e5d7c0 100644
--- a/arch/arm/mach-k3/j721s2/dev-data.c
+++ b/arch/arm/mach-k3/j721s2/dev-data.c
@@ -47,6 +47,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
};
static struct ti_dev soc_dev_list[] = {
+ PSC_DEV(35, _lpsc_list[0]),
PSC_DEV(108, _lpsc_list[0]),
PSC_DEV(109, _lpsc_list[0]),
PSC_DEV(110, _lpsc_list[0]),
--
2.41.0
[PATCH v6 2/7] Revert "arm: dts: k3-j7*: ddr: Update to 0.10 version of DDR config tool"
The update causes instability in am68-sk boards so revert the patch in the meantime till fix is available. This reverts commit f1edf4bb6aa19732574ac23ca90cb9a0ba395ec1. Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi | 98 +++--- arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi | 464 +-- 2 files changed, 281 insertions(+), 281 deletions(-) diff --git a/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi b/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi index a0285ce0520e..5a6f9b11b8e3 100644 --- a/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi +++ b/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi @@ -1,9 +1,9 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/ - * This file was generated by the Jacinto7_DDRSS_RegConfigTool, Revision: 0.10.0 - * This file was generated on 04/12/2023 - */ + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + * This file was generated by the Jacinto7_DDRSS_RegConfigTool, Revision: 0.9.1 + * This file was generated on 07/17/2022 +*/ #define DDRSS_PLL_FHS_CNT 10 #define DDRSS_PLL_FREQUENCY_0 2750 @@ -54,11 +54,11 @@ #define DDRSS_CTL_41_DATA 0x1B60008B #define DDRSS_CTL_42_DATA 0x2000422B #define DDRSS_CTL_43_DATA 0x000A0A09 -#define DDRSS_CTL_44_DATA 0x040003C5 +#define DDRSS_CTL_44_DATA 0x0400078A #define DDRSS_CTL_45_DATA 0x1E161104 -#define DDRSS_CTL_46_DATA 0x1000922C +#define DDRSS_CTL_46_DATA 0x10012458 #define DDRSS_CTL_47_DATA 0x1E161110 -#define DDRSS_CTL_48_DATA 0x1000922C +#define DDRSS_CTL_48_DATA 0x10012458 #define DDRSS_CTL_49_DATA 0x02030410 #define DDRSS_CTL_50_DATA 0x2C040500 #define DDRSS_CTL_51_DATA 0x082D2C2D @@ -71,11 +71,11 @@ #define DDRSS_CTL_58_DATA 0x00010100 #define DDRSS_CTL_59_DATA 0x0301 #define DDRSS_CTL_60_DATA 0x1008 -#define DDRSS_CTL_61_DATA 0x0063 +#define DDRSS_CTL_61_DATA 0x00CE #define DDRSS_CTL_62_DATA 0x0256 -#define DDRSS_CTL_63_DATA 0x1035 +#define DDRSS_CTL_63_DATA 0x2073 #define DDRSS_CTL_64_DATA 0x0256 -#define DDRSS_CTL_65_DATA 0x1035 +#define DDRSS_CTL_65_DATA 0x2073 #define DDRSS_CTL_66_DATA 0x0005 #define DDRSS_CTL_67_DATA 0x0004 #define DDRSS_CTL_68_DATA 0x00950012 @@ -112,27 +112,27 @@ #define DDRSS_CTL_99_DATA 0x #define DDRSS_CTL_100_DATA 0x00040005 #define DDRSS_CTL_101_DATA 0x -#define DDRSS_CTL_102_DATA 0x18C0 -#define DDRSS_CTL_103_DATA 0x18C0 -#define DDRSS_CTL_104_DATA 0x18C0 -#define DDRSS_CTL_105_DATA 0x18C0 -#define DDRSS_CTL_106_DATA 0x18C0 +#define DDRSS_CTL_102_DATA 0x3380 +#define DDRSS_CTL_103_DATA 0x3380 +#define DDRSS_CTL_104_DATA 0x3380 +#define DDRSS_CTL_105_DATA 0x3380 +#define DDRSS_CTL_106_DATA 0x3380 #define DDRSS_CTL_107_DATA 0x -#define DDRSS_CTL_108_DATA 0x02B5 -#define DDRSS_CTL_109_DATA 0x00040D40 -#define DDRSS_CTL_110_DATA 0x00040D40 -#define DDRSS_CTL_111_DATA 0x00040D40 -#define DDRSS_CTL_112_DATA 0x00040D40 -#define DDRSS_CTL_113_DATA 0x00040D40 +#define DDRSS_CTL_108_DATA 0x05A2 +#define DDRSS_CTL_109_DATA 0x00081CC0 +#define DDRSS_CTL_110_DATA 0x00081CC0 +#define DDRSS_CTL_111_DATA 0x00081CC0 +#define DDRSS_CTL_112_DATA 0x00081CC0 +#define DDRSS_CTL_113_DATA 0x00081CC0 #define DDRSS_CTL_114_DATA 0x -#define DDRSS_CTL_115_DATA 0x7173 -#define DDRSS_CTL_116_DATA 0x00040D40 -#define DDRSS_CTL_117_DATA 0x00040D40 -#define DDRSS_CTL_118_DATA 0x00040D40 -#define DDRSS_CTL_119_DATA 0x00040D40 -#define DDRSS_CTL_120_DATA 0x00040D40 +#define DDRSS_CTL_115_DATA 0xE325 +#define DDRSS_CTL_116_DATA 0x00081CC0 +#define DDRSS_CTL_117_DATA 0x00081CC0 +#define DDRSS_CTL_118_DATA 0x00081CC0 +#define DDRSS_CTL_119_DATA 0x00081CC0 +#define DDRSS_CTL_120_DATA 0x00081CC0 #define DDRSS_CTL_121_DATA 0x -#define DDRSS_CTL_122_DATA 0x7173 +#define DDRSS_CTL_122_DATA 0xE325 #define DDRSS_CTL_123_DATA 0x #define DDRSS_CTL_124_DATA 0x #define DDRSS_CTL_125_DATA 0x @@ -399,29 +399,29 @@ #define DDRSS_CTL_386_DATA 0x #define DDRSS_CTL_387_DATA 0x3A3A1B00 #define DDRSS_CTL_388_DATA 0x000A -#define DDRSS_CTL_389_DATA 0x00C6 +#define DDRSS_CTL_389_DATA 0x019C #define DDRSS_CTL_390_DATA 0x0200 #define DDRSS_CTL_391_DATA 0x0200 #define DDRSS_CTL_392_DATA 0x0200 #define DDRSS_CTL_393_DATA 0x0200 -#define DDRSS_CTL_394_DATA 0x0252 -#define DDRSS_CTL_395_DATA 0x07BC +#define DDRSS_CTL_394_DATA 0x04D4 +#define DDRSS_CTL_395_DATA 0x1018 #define DDRSS_CTL_396_DATA 0x0204 -#define DDRSS_CTL_397_DATA 0x206A +#define DDRSS_CTL_397_DATA 0x40E6 #define DDRSS_CTL_398_DATA 0x0200 #define DDRSS_CTL_399_DATA 0x0200 #define DDRSS_CTL_400_DATA 0x0200 #define DDRSS_CTL_401_DATA 0x0200 -#define DDRSS_CTL_402_DATA 0x613E -#define DDRSS_CTL_403_DATA 0x00014424 +#define DDRSS_CTL_402_DATA 0xC2B2 +#define
[PATCH v6 1/7] configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM
From: Udit Kumar The malloc capacity in DRAM at R5 SPL is set to 1MB which isn't sufficient to load the new tispl.bin to enable loading of tispl.bin the size is increased by 256KB to 1.25MB. Cc: Nikhil M Jain Signed-off-by: Udit Kumar Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- configs/j721s2_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig index 1e66ac23d05b..e2b83b337809 100644 --- a/configs/j721s2_evm_r5_defconfig +++ b/configs/j721s2_evm_r5_defconfig @@ -42,6 +42,7 @@ CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x14 CONFIG_SPL_SEPARATE_BSS=y CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y -- 2.41.0
[PATCH v6 0/7] J721S2 DTS Sync from v6.6-rc1 to u-boot
The sync tries to ensure that U-boot remains functional with the updated Linux DTS and all the fixes from Linux move to U-boot during the sync. The series tries to sync from Linux v6.6-rc1 along with addition of the documentation for J721S2 that had been previously missing. DMA fixes [0] are currently being upstreamed to Linux. Test Logs are included in [1] [0]: https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [1]: https://gist.github.com/manorit2001/dbad09fd00e8b7c3872e85874c8e648c Signed-off-by: Manorit Chawdhry --- Changes in v6: - Update the subject prefixes ( Nishanth ) - Link to v5: https://lore.kernel.org/r/20230919-b4-upstream-j721s2-r5-pinmux-v5-0-a54d6ee26...@ti.com --- Manorit Chawdhry (6): Revert "arm: dts: k3-j7*: ddr: Update to 0.10 version of DDR config tool" arm: mach-k3: j721s2: Add mcu_timer0 id to the dev list arm: dts: k3-j721s2: Sync from Linux tag v6.6-rc1 arm: dts: k3-am68: Sync from Linux tag v6.6-rc1 docs: board: ti: Add j721s2_evm documentation board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File. Udit Kumar (1): configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 75 +- arch/arm/dts/k3-am68-sk-base-board.dts | 524 +- arch/arm/dts/k3-am68-sk-r5-base-board.dts | 151 +--- arch/arm/dts/k3-am68-sk-som.dtsi | 112 +-- arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi| 98 +-- .../dts/k3-j721s2-common-proc-board-u-boot.dtsi| 66 +- arch/arm/dts/k3-j721s2-common-proc-board.dts | 376 ++ arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi | 464 ++-- arch/arm/dts/k3-j721s2-main.dtsi | 777 - arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 374 +- arch/arm/dts/k3-j721s2-r5-common-proc-board.dts| 158 + arch/arm/dts/k3-j721s2-som-p0.dtsi | 172 ++--- arch/arm/dts/k3-j721s2-thermal.dtsi| 101 +++ arch/arm/dts/k3-j721s2.dtsi| 12 +- arch/arm/dts/k3-serdes.h | 204 ++ arch/arm/mach-k3/j721s2/dev-data.c | 1 + board/ti/j721s2/MAINTAINERS| 11 +- configs/j721s2_evm_r5_defconfig| 1 + doc/board/ti/j721s2_evm.rst| 341 + doc/board/ti/k3.rst| 1 + 20 files changed, 2859 insertions(+), 1160 deletions(-) --- base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c change-id: 20230816-b4-upstream-j721s2-r5-pinmux-25c4cd61b258 Best regards, -- Manorit Chawdhry
[PATCH v2] env: ti: ti_common.env: Fix get_overlaystring for FIT Image
After the refactor with conf- nodes in fitImage, overlaystring wasn't
didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
to handle conf- nodes.
Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get FIT
config string")
Reported-by: Aniket Limaye
Signed-off-by: Manorit Chawdhry
---
Test Logs:
=> setenv name_overlays ti/k3-dt.dtbo ti/k3-dt1.dtbo
=> run get_overlaystring
=> printenv overlaystring
overlaystring=#conf-ti_k3-dt.dtbo#conf-ti_k3-dt1.dtbo
---
Changes in v2:
- Fix tabs
- Link to v1:
https://lore.kernel.org/r/20230919-b4-upstream-overlaystring-v1-1-4c56e8d66...@ti.com
---
include/env/ti/ti_common.env | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
index e87a41a6590b..bc554fe7ca6d 100644
--- a/include/env/ti/ti_common.env
+++ b/include/env/ti/ti_common.env
@@ -16,9 +16,14 @@ addr_fit=0x9000
name_fit=fitImage
update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
get_overlaystring=
- for overlay in $name_overlays;
- do;
- setenv overlaystring ${overlaystring}'#'${overlay};
+ for overlay in $name_overlays; do;
+ if test ${boot_fit} -eq 1;
+ then
+ setexpr name_fit_overlay gsub / _
conf-${overlay};
+ setenv overlaystring
${overlaystring}'#'${name_fit_overlay};
+ else
+ setenv overlaystring
${overlaystring}'#'${overlay};
+ fi;
done;
get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
run_fit=run get_fit_config; bootm
${addr_fit}#${name_fit_config}${overlaystring}
---
base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
change-id: 20230915-b4-upstream-overlaystring-207e28b8c5fb
Best regards,
--
Manorit Chawdhry
[PATCH 1/1] cmd/exception: test RISC-V 16 bit aligned instruction
A 16 bit aligned instruction should generated an exception if the C
extension is not available.
Provide an 'extension ialign16' command for testing exception handling.
For testing build qemu-riscv64_defconfig with CONFIG_RISCV_ISA_C=n
and run with
qemu-system-riscv64 -M virt -bios u-boot -nographic -cpu rv64,c=false
=> exception ialign16
Unhandled exception: Instruction address misaligned
EPC: 87719138 RA: 87719218 TVAL: 8771913e
EPC: 80020138 RA: 80020218 reloc adjusted
Code: 0113 0101 8067 0113 ff01 3423 0011 (006f 0060)
Signed-off-by: Heinrich Schuchardt
---
cmd/riscv/exception.c | 16
1 file changed, 16 insertions(+)
diff --git a/cmd/riscv/exception.c b/cmd/riscv/exception.c
index db8d8af048..f38f454a0b 100644
--- a/cmd/riscv/exception.c
+++ b/cmd/riscv/exception.c
@@ -24,6 +24,19 @@ static int do_ebreak(struct cmd_tbl *cmdtp, int flag, int
argc,
return CMD_RET_FAILURE;
}
+static int do_ialign16(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ asm volatile (
+ /* jump skipping 2 bytes */
+ ".long 0x0060006f\n"
+ ".long 0x006f\n"
+ ".long 0x0060\n"
+ );
+ printf("The system supports 16 bit aligned instructions.\n");
+ return CMD_RET_SUCCESS;
+}
+
static int do_unaligned(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -48,6 +61,8 @@ static struct cmd_tbl cmd_sub[] = {
"", ""),
U_BOOT_CMD_MKENT(ebreak, CONFIG_SYS_MAXARGS, 1, do_ebreak,
"", ""),
+ U_BOOT_CMD_MKENT(ialign16, CONFIG_SYS_MAXARGS, 1, do_ialign16,
+"", ""),
U_BOOT_CMD_MKENT(unaligned, CONFIG_SYS_MAXARGS, 1, do_unaligned,
"", ""),
U_BOOT_CMD_MKENT(undefined, CONFIG_SYS_MAXARGS, 1, do_undefined,
@@ -59,6 +74,7 @@ static char exception_help_text[] =
" The following exceptions are available:\n"
" compressed - compressed instruction\n"
" ebreak - breakpoint\n"
+ " ialign16 - 16 bit aligned instruction\n"
" undefined - illegal instruction\n"
" unaligned - load address misaligned\n"
;
--
2.40.1
Re: [PATCH v7 2/2] serial: zynqmp: Fetch baudrate from dtb and update
On 9/21/23 06:21, Venkatesh Yadav Abbarapu wrote:
From: Algapally Santosh Sagar
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
---
doc/README.serial_dt_baud | 41
drivers/core/ofnode.c | 18 ++
drivers/serial/Kconfig | 9 +++
drivers/serial/serial-uclass.c | 43 ++
include/dm/ofnode.h| 14 +--
include/env_default.h | 6 -
include/serial.h | 15
7 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 doc/README.serial_dt_baud
diff --git a/doc/README.serial_dt_baud b/doc/README.serial_dt_baud
new file mode 100644
index 00..f8768d0e1b
--- /dev/null
+++ b/doc/README.serial_dt_baud
@@ -0,0 +1,41 @@
+Fetch serial baudrate from DT
+-
+
+To support fetching of baudrate from DT, the following is done:-
+
+The baudrate configured in Kconfig symbol CONFIG_BAUDRATE is taken by default
by serial.
+If change of baudrate is required then the Kconfig symbol CONFIG_BAUDRATE
needs to
+changed and U-Boot recompilation is required or the U-Boot environment needs
to be updated.
+
+To avoid this, add support to fetch the baudrate directly from the device tree
file and
+update the environment.
+
+The default environment stores the default baudrate value. When default
baudrate and dtb
+baudrate are not same glitches are seen on the serial.
+So, the environment also needs to be updated with the dtb baudrate to avoid
the glitches on
+the serial which is enabled by OF_SERIAL_BAUD.
+
+The Kconfig SPL_ENV_SUPPORT needs to be enabled to allow patching in SPL.
+
+The Kconfig DEFAULT_ENV_IS_RW which is enabled by OF_SERIAL_BAUD with making
the environment
+writable.
+
+The ofnode_read_baud() function parses and fetches the baudrate value from the
DT. This value
+is validated and updated to baudrate during serial init. Padding is added at
the end of the
+default environment and the dt baudrate is updated with the latest value.
+
+Example:-
+
+The serial port options are of the form "pnf", where "" is the baud rate, "p" is parity
("n", "o", or "e"),
+"n" is number of bits, and "f" is flow control ("r" for RTS or omit it). Default is
"115200n8".
+
+chosen {
+ bootargs = "earlycon console=ttyPS0,115200 clk_ignore_unused
root=/dev/ram0 rw init_fatal_sh=1";
+ stdout-path = "serial0:115200n8";
+ };
+
+From the chosen node, stdout-path property is obtained as string.
+
+ stdout-path = "serial0:115200n8";
+
+The string is parsed to get the baudrate 115200. This string is converted to
integer and updated to the environment.
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af..42f51ca93c 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -895,6 +895,24 @@ ofnode ofnode_get_chosen_node(const char *name)
return ofnode_path(prop);
}
+int ofnode_read_baud(void)
I expect Simon will want to have test to cover this too.
+{
+ const char *str, *p;
+ u32 baud;
+
+ str = ofnode_read_chosen_string("stdout-path");
+ if (!str)
+ return -EINVAL;
+
+ /* Parse string serial0:115200n8 */
+ p = strchr(str, ':');
+ if (!p)
+ return -EINVAL;
+
+ baud = dectoul(p + 1, NULL);
+ return baud;
+}
+
const void *ofnode_read_aliases_prop(const char *propname, int *sizep)
{
ofnode node;
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 4d27034c3f..7fdf600dc5 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -24,6 +24,15 @@ config BAUDRATE
in the SPL stage (most drivers) or for choosing a default baudrate
in the absence of an environment setting (serial_mxc.c).
+config OF_SERIAL_BAUD
+ bool "Fetch serial baudrate from device tree"
+ depends on DM_SERIAL && SPL_ENV_SUPPORT
+ select DEFAULT_ENV_IS_RW
+ help
+ Select this to enable fetching and setting of the baudrate
+ configured in the DT. Replace the default baudrate with
Re: [PATCH] env: ti: ti_common.env: Fix get_overlaystring for FIT Image
Hi
On 10:28-20230919, Manorit Chawdhry wrote:
> After the refactor with conf- nodes in fitImage, overlaystring wasn't
> didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
> to handle conf- nodes.
>
> Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get FIT
> config string")
> Reported-by: Aniket Limaye
> Signed-off-by: Manorit Chawdhry
> ---
> Test Logs:
> => setenv name_overlays ti/k3-dt.dtbo ti/k3-dt1.dtbo
> => run get_overlaystring
> => printenv overlaystring
> overlaystring=#conf-ti_k3-dt.dtbo#conf-ti_k3-dt1.dtbo
> ---
> include/env/ti/ti_common.env | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
> index e87a41a6590b..4d0590912614 100644
> --- a/include/env/ti/ti_common.env
> +++ b/include/env/ti/ti_common.env
> @@ -16,9 +16,14 @@ addr_fit=0x9000
> name_fit=fitImage
> update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
> get_overlaystring=
> - for overlay in $name_overlays;
> - do;
> - setenv overlaystring ${overlaystring}'#'${overlay};
> + for overlay in $name_overlays; do;
> +if test ${boot_fit} -eq 1;
> + then
> +setexpr name_fit_overlay gsub / _ conf-${overlay};
> +setenv overlaystring ${overlaystring}'#'${name_fit_overlay};
> + else
> +setenv overlaystring ${overlaystring}'#'${overlay};
> +fi;
Checkpatch didn't comment but see tabs and spaces mixed in the file...
Would re-roll with the fix.
Regards,
Manorit
> done;
> get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
> run_fit=run get_fit_config; bootm
> ${addr_fit}#${name_fit_config}${overlaystring}
>
> ---
> base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
> change-id: 20230915-b4-upstream-overlaystring-207e28b8c5fb
>
> Best regards,
> --
> Manorit Chawdhry
>
