Re: [PATCH v2] bootstage: Show func name for bootstage_mark/error
so 13. 8. 2022 v 4:21 odesílatel Simon Glass napsal: > > Hi Michal, > > On Fri, 12 Aug 2022 at 02:55, Michal Simek wrote: > > > > bootstage_mark() and bootstate_error() are not recording any name and in > > report it is showing as id=. That's not useful and it is better to > > show function name which calls it. > > That's why use macros with passing __func__ as recorded name for bootstage. > > > > Origin report looks like this: > > ZynqMP> bootstage report > > Timer summary in microseconds (10 records): > >MarkElapsed Stage > > 0 0 reset > > 2,482,383 2,482,383 board_init_f > > 4,278,821 1,796,438 board_init_r > > 4,825,331546,510 id=64 > > 4,858,409 33,078 id=65 > > 4,862,382 3,973 main_loop > > 4,921,713 59,331 usb_start > > 9,345,345 4,423,632 id=175 > > > > When this patch is applied. > > ZynqMP> bootstage report > > Timer summary in microseconds (31 records): > >MarkElapsed Stage > > 0 0 reset > > 2,465,624 2,465,624 board_init_f > > 4,278,628 1,813,004 board_init_r > > 4,825,139546,511 eth_common_init > > 4,858,228 33,089 eth_initialize > > 4,862,201 3,973 main_loop > > 4,921,530 59,329 usb_start > > 8,885,334 3,963,804 cli_loop > > > > Signed-off-by: Michal Simek > > --- > > > > Changes in v2: > > - Add kernel-doc description > > > > common/bootstage.c | 10 ++ > > include/bootstage.h | 21 ++--- > > 2 files changed, 20 insertions(+), 11 deletions(-) > > I can see what is going on here after applying it. > > Reviewed-by: Simon Glass > > But I think it would be better as inline functions rather than #define I was trying static inline functions but __func__ is using bootstage names instead of the function which is calling them. Maybe there is another function specifier which can be used to do the same job as macros. Thanks, Michal
Re: [RFC PATCH v1 3/9] clk: renesas: add R906G032 driver
On 8/9/22 8:59 AM, Ralph Siemsen wrote:
Clock driver for the Renesas RZ/N1 SoC family. This is based
on the Linux kernel drivers/clk/renesas/r9a06g032-clocks.c.
Notable difference: this version avoids allocating a 'struct clk'
for each clock source, as this is problematic before relocation.
Instead, it uses the same approach as existing Renesas RCAR2/3
clock drivers, using a temporary structure filled on-the-fly.
Signed-off-by: Ralph Siemsen
---
- TODO: add support for div_table
drivers/clk/renesas/Kconfig| 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a06g032-clocks.c | 734 +
3 files changed, 741 insertions(+)
create mode 100644 drivers/clk/renesas/r9a06g032-clocks.c
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index c53ff3ce01..e2f72fc04f 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -120,3 +120,9 @@ config CLK_R8A779A0
depends on CLK_RCAR_GEN3
help
Enable this to support the clocks on Renesas R8A779A0 SoC.
+
+config CLK_R9A06G032
+ bool "Renesas R9A06G032 clock driver"
+ depends on CLK_RENESAS
+ help
+ Enable this to support the clocks on Renesas R9A06G032 SoC.
nit: on the
...
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 2cd2c69f68..9981f1a0bc 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_CLK_R8A77980) += r8a77980-cpg-mssr.o
obj-$(CONFIG_CLK_R8A77990) += r8a77990-cpg-mssr.o
obj-$(CONFIG_CLK_R8A77995) += r8a77995-cpg-mssr.o
obj-$(CONFIG_CLK_R8A779A0) += r8a779a0-cpg-mssr.o
+obj-$(CONFIG_CLK_R9A06G032) += r9a06g032-clocks.o
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c
b/drivers/clk/renesas/r9a06g032-clocks.c
new file mode 100644
index 00..9c8f51eb96
--- /dev/null
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -0,0 +1,734 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R9A06G032 clock driver
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet ,
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct r9a06g032_gate {
Can you add some documentation for each of the fields? Same for
r9a06g032_clkdesc.
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
+ u16 gate, reset, ready, midle,
+ scon, mirack, mistat;
What are the scon/mirack/mistat fields for? You define them for a lot
of clocks, but I don't see them used in the driver.
+};
+
+/* This is used to describe a clock for instantiation */
+struct r9a06g032_clkdesc {
+ const char *name;
+ uint32_t managed: 1;
+ uint32_t type: 3;
I wonder if we could define the enum here?
+ uint32_t index: 8;
+ uint32_t source : 8; /* source index + 1 (0 == none) */
+ /* these are used to populate the bitsel struct */
+ union {
+ struct r9a06g032_gate gate;
+ /* for dividers */
+ struct {
+ unsigned int div_min : 10, div_max : 10, reg: 10;
+ u16 div_table[4];
+ };
+ /* For fixed-factor ones */
+ struct {
+ u16 div, mul;
+ };
+ /* for dual gate */
+ struct {
+ uint16_t group : 1;
+ u16 sel, g1, r1, g2, r2;
+ } dual;
+ };
+};
+
+#define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
+ { .gate = _clk, .reset = _rst, \
If these fields have bitfield inside them, then those bitfields should
be assigned/constructed separately. That is, if .reset is actually a combined
offset/bit, then you need to expose those in the macro. Since you have a lot of
these, you might want to do something like
#define BIT_OFFSET GENMASK(15, 5)
#define BIT_SHIFT GENMASK(4, 0)
#define PACK_BIT(offset, shift) (FIELD_PREP(BIT_OFFSET, offset) |
FIELD_PREP(BIT_SHIFT, shift))
+ .ready = _rdy, .midle = _midle, \
+ .scon = _scon, .mirack = _mirack, .mistat = _mistat }
Please put each assignment on a separate line
+#define D_GATE(_idx, _n, _src, ...) \
+ { .type = K_GATE, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .gate = I_GATE(__VA_ARGS__) }
+#define D_MODULE(_idx, _n, _src, ...) \
+ { .type = K_GATE, .index = R9A06G032_##_idx, \
+ .source = 1 + R9A06G032_##_src, .name = _n, \
+ .managed = 1, .gate = I_GATE(__VA_ARGS__) }
+#define D_ROOT(_idx, _n, _mul, _div) \
+ { .type = K_FFC, .index = R9A06G032_##_idx, .name = _n, \
+ .div = _div, .mul = _mul }
+#define D_FFC(_idx, _n, _src, _div) \
+ { .type = K_FFC, .index = R9A06G032_##_idx, \
+
Re: [RFC PATCH v1 2/9] clk: renesas: prepare for non-RCAR clock drivers
On 8/9/22 8:59 AM, Ralph Siemsen wrote: Allow CONFIG_CLK_RENESAS to be set without bringing in RCAR-GEN2/3 code. CONFIG_RENESAS is used in drivers/clk/Makefile to control recursion into the drivers/clk/renesas subdirectory. It also controls compilation of renesas-cpg-mssr.c support code for the RCAR-GEN2 and RCAR-GEN3 devices. The support code contains platform specific hardware access (TMU_BASE), and it is not needed for other Renesas devices such as RZ/N1. Therefore, alter Makefile to build renesas-cpg-mssr.c only for RCAR-GEN2 and RCAR-GEN3. Signed-off-by: Ralph Siemsen --- drivers/clk/renesas/Kconfig | 2 +- drivers/clk/renesas/Makefile | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index f4d6ef9f93..c53ff3ce01 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -1,6 +1,6 @@ config CLK_RENESAS bool "Renesas clock drivers" - depends on CLK && ARCH_RMOBILE + depends on CLK && (ARCH_RMOBILE || ARCH_RZN1) help Enable support for clock present on Renesas RCar SoCs. diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile index 36a5ca65f4..2cd2c69f68 100644 --- a/drivers/clk/renesas/Makefile +++ b/drivers/clk/renesas/Makefile @@ -1,5 +1,4 @@ -obj-$(CONFIG_CLK_RENESAS) += renesas-cpg-mssr.o -obj-$(CONFIG_CLK_RCAR_GEN2) += clk-rcar-gen2.o +obj-$(CONFIG_CLK_RCAR_GEN2) += clk-rcar-gen2.o renesas-cpg-mssr.o obj-$(CONFIG_CLK_R8A774A1) += r8a774a1-cpg-mssr.o obj-$(CONFIG_CLK_R8A774B1) += r8a774b1-cpg-mssr.o obj-$(CONFIG_CLK_R8A774C0) += r8a774c0-cpg-mssr.o @@ -9,7 +8,7 @@ obj-$(CONFIG_CLK_R8A7791) += r8a7791-cpg-mssr.o obj-$(CONFIG_CLK_R8A7792) += r8a7792-cpg-mssr.o obj-$(CONFIG_CLK_R8A7793) += r8a7791-cpg-mssr.o obj-$(CONFIG_CLK_R8A7794) += r8a7794-cpg-mssr.o -obj-$(CONFIG_CLK_RCAR_GEN3) += clk-rcar-gen3.o +obj-$(CONFIG_CLK_RCAR_GEN3) += clk-rcar-gen3.o renesas-cpg-mssr.o obj-$(CONFIG_CLK_R8A7795) += r8a7795-cpg-mssr.o obj-$(CONFIG_CLK_R8A7796) += r8a7796-cpg-mssr.o obj-$(CONFIG_CLK_R8A77965) += r8a77965-cpg-mssr.o Reviewed-by: Sean Anderson
Re: [RFC PATCH 1/1] spl: introduce SPL_XIP to config
Hi Nikita,
On 8/11/22 5:37 AM, Nikita Shubin wrote:
From: Nikita Shubin
U-Boot and SPL don't necessary share the same location, so we might end
with XIP SPL and U-Boot in "normal" memory.
This adds an option special for SPL to behave it in XIP manner and don't
use hart_lottery and available_harts_lock.
Signed-off-by: Nikita Shubin
---
On a stylistic note, typically cover letters are not used for single
patches (but feel free to use them for larger series).
arch/riscv/cpu/cpu.c | 2 +-
arch/riscv/cpu/start.S | 4 ++--
arch/riscv/include/asm/global_data.h | 2 +-
arch/riscv/lib/asm-offsets.c | 2 +-
arch/riscv/lib/smp.c | 2 +-
common/spl/Kconfig | 5 +
include/configs/scr7_vcu118.h| 2 ++
7 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 9f5fa0bcb3..89528748d7 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -19,7 +19,7 @@
* The variables here must be stored in the data section since they are used
* before the bss section is available.
*/
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
Shouldn't this be
#if CONFIG_IS_ENABLED(XIP)
?
ditto for the rest of these
u32 hart_lottery __section(".data") = 0;
/*
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 26cb877ed1..d824990778 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -122,7 +122,7 @@ call_board_init_f_0:
call_harts_early_init:
jal harts_early_init
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
/*
* Pick hart to initialize global data and run U-Boot. The other harts
* wait for initialization to complete.
@@ -155,7 +155,7 @@ call_harts_early_init:
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
la t0, available_harts_lock
amoswap.w.rl zero, zero, 0(t0)
diff --git a/arch/riscv/include/asm/global_data.h b/arch/riscv/include/asm/global_data.h
index 9a146d1d49..d71e09c5ab 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -30,7 +30,7 @@ int iccm[CONFIG_NR_CPUS];
#if CONFIG_IS_ENABLED(SMP)
struct ipi_data ipi[CONFIG_NR_CPUS];
#endif
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
ulong available_harts;
#endif
};
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index f1fe089b3d..bcb3c78654 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -16,7 +16,7 @@ int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index ba992100ad..cef324954c 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -45,7 +45,7 @@ static int send_ipi_many(struct ipi_data *ipi, int wait)
continue;
}
-#ifndef CONFIG_XIP
+#if !defined(CONFIG_XIP) && !defined(CONFIG_SPL_XIP)
/* skip if hart is not available */
if (!(gd->arch.available_harts & (1 << reg)))
continue;
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 07c03d611d..f24e423fc0 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -27,6 +27,11 @@ config SPL_FRAMEWORK
supports MMC, NAND and YMODEM and other methods loading of U-Boot
and the Linux Kernel. If unsure, say Y.
+config SPL_XIP
+ bool "Support SPL in XIP"
+ help
+ Enable this if SPL is in XIP memory.
Can you add another sentence or two? What is "XIP memory"? How does it differ
from the standard boot process?
Also, it seems like we already have SPL_XIP_SUPPORT. Maybe we can reuse that?
config SPL_FRAMEWORK_BOARD_INIT_F
bool "Define a generic function board_init_f"
depends on SPL_FRAMEWORK
diff --git a/include/configs/scr7_vcu118.h b/include/configs/scr7_vcu118.h
index 34545255d1..8f3ba36ce1 100644
--- a/include/configs/scr7_vcu118.h
+++ b/include/configs/scr7_vcu118.h
@@ -29,6 +29,8 @@
#define SCR7_OCRAM_REGION_SIZE0x
#define SCR7L2_CACHE1
+
+#define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE
#endif
#define CONFIG_SYS_FLASH_BASE 0x0f03
What is this part doing? It's not mentioned in the commit message.
--Sean
Re: [PATCH 27/31] clk: mediatek: add clock driver support for MediaTek MT7981 SoC
On 8/3/22 11:36 PM, Weijie Gao wrote:
This patch adds clock driver support for MediaTek MT7981 SoC
Signed-off-by: Weijie Gao
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt7981.c | 682 +
include/dt-bindings/clock/mt7981-clk.h | 267 ++
3 files changed, 950 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt7981.c
create mode 100644 include/dt-bindings/clock/mt7981-clk.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 1aa38215bf..1decf31a77 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
obj-$(CONFIG_TARGET_MT7622) += clk-mt7622.o
obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
obj-$(CONFIG_TARGET_MT7986) += clk-mt7986.o
+obj-$(CONFIG_TARGET_MT7981) += clk-mt7981.o
obj-$(CONFIG_TARGET_MT8183) += clk-mt8183.o
obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
diff --git a/drivers/clk/mediatek/clk-mt7981.c
b/drivers/clk/mediatek/clk-mt7981.c
new file mode 100644
index 00..53d09250e6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7981.c
@@ -0,0 +1,682 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT7981 SoC
+ *
+ * Copyright (C) 2022 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+#define MT7981_CLK_PDN 0x250
+#define MT7981_CLK_PDN_EN_WRITE BIT(31)
+
+#define PLL_FACTOR(_id, _name, _parent, _mult, _div)
\
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
+
+#define TOP_FACTOR(_id, _name, _parent, _mult, _div)
\
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
+
+#define INFRA_FACTOR(_id, _name, _parent, _mult, _div)
\
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_INFRASYS)
+
+/* FIXED PLLS */
+static const struct mtk_fixed_clk fixed_pll_clks[] = {
+ FIXED_CLK(CK_APMIXED_ARMPLL, CLK_XTAL, 13),
+ FIXED_CLK(CK_APMIXED_NET2PLL, CLK_XTAL, 8),
+ FIXED_CLK(CK_APMIXED_MMPLL, CLK_XTAL, 72000),
+ FIXED_CLK(CK_APMIXED_SGMPLL, CLK_XTAL, 32500),
+ FIXED_CLK(CK_APMIXED_WEDMCUPLL, CLK_XTAL, 20800),
+ FIXED_CLK(CK_APMIXED_NET1PLL, CLK_XTAL, 25),
+ FIXED_CLK(CK_APMIXED_MPLL, CLK_XTAL, 41600),
+ FIXED_CLK(CK_APMIXED_APLL2, CLK_XTAL, 196608000),
+};
+
+/* TOPCKGEN FIXED CLK */
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+ FIXED_CLK(CK_TOP_CB_CKSQ_40M, CLK_XTAL, 4000),
+};
+
+/* TOPCKGEN FIXED DIV */
+static const struct mtk_fixed_factor top_fixed_divs[] = {
+ PLL_FACTOR(CK_TOP_CB_M_416M, "cb_m_416m", CK_APMIXED_MPLL, 1, 1),
+ PLL_FACTOR(CK_TOP_CB_M_D2, "cb_m_d2", CK_APMIXED_MPLL, 1, 2),
+ PLL_FACTOR(CK_TOP_CB_M_D3, "cb_m_d3", CK_APMIXED_MPLL, 1, 3),
+ PLL_FACTOR(CK_TOP_M_D3_D2, "m_d3_d2", CK_APMIXED_MPLL, 1, 2),
+ PLL_FACTOR(CK_TOP_CB_M_D4, "cb_m_d4", CK_APMIXED_MPLL, 1, 4),
+ PLL_FACTOR(CK_TOP_CB_M_D8, "cb_m_d8", CK_APMIXED_MPLL, 1, 8),
+ PLL_FACTOR(CK_TOP_M_D8_D2, "m_d8_d2", CK_APMIXED_MPLL, 1, 16),
+ PLL_FACTOR(CK_TOP_CB_MM_720M, "cb_mm_720m", CK_APMIXED_MMPLL, 1, 1),
+ PLL_FACTOR(CK_TOP_CB_MM_D2, "cb_mm_d2", CK_APMIXED_MMPLL, 1, 2),
+ PLL_FACTOR(CK_TOP_CB_MM_D3, "cb_mm_d3", CK_APMIXED_MMPLL, 1, 3),
+ PLL_FACTOR(CK_TOP_CB_MM_D3_D5, "cb_mm_d3_d5", CK_APMIXED_MMPLL, 1, 15),
+ PLL_FACTOR(CK_TOP_CB_MM_D4, "cb_mm_d4", CK_APMIXED_MMPLL, 1, 4),
+ PLL_FACTOR(CK_TOP_CB_MM_D6, "cb_mm_d6", CK_APMIXED_MMPLL, 1, 6),
+ PLL_FACTOR(CK_TOP_MM_D6_D2, "mm_d6_d2", CK_APMIXED_MMPLL, 1, 12),
+ PLL_FACTOR(CK_TOP_CB_MM_D8, "cb_mm_d8", CK_APMIXED_MMPLL, 1, 8),
+ PLL_FACTOR(CK_TOP_CB_APLL2_196M, "cb_apll2_196m", CK_APMIXED_APLL2, 1,
+ 1),
+ PLL_FACTOR(CK_TOP_APLL2_D2, "apll2_d2", CK_APMIXED_APLL2, 1, 2),
+ PLL_FACTOR(CK_TOP_APLL2_D4, "apll2_d4", CK_APMIXED_APLL2, 1, 4),
+ PLL_FACTOR(CK_TOP_NET1_2500M, "net1_2500m", CK_APMIXED_NET1PLL, 1, 1),
+ PLL_FACTOR(CK_TOP_CB_NET1_D4, "cb_net1_d4", CK_APMIXED_NET1PLL, 1, 4),
+ PLL_FACTOR(CK_TOP_CB_NET1_D5, "cb_net1_d5", CK_APMIXED_NET1PLL, 1, 5),
+ PLL_FACTOR(CK_TOP_NET1_D5_D2, "net1_d5_d2", CK_APMIXED_NET1PLL, 1, 10),
+ PLL_FACTOR(CK_TOP_NET1_D5_D4, "net1_d5_d4", CK_APMIXED_NET1PLL, 1, 20),
+ PLL_FACTOR(CK_TOP_CB_NET1_D8, "cb_net1_d8", CK_APMIXED_NET1PLL, 1, 8),
+ PLL_FACTOR(CK_TOP_NET1_D8_D2, "net1_d8_d2", CK_APMIXED_NET1PLL, 1, 16),
+ PLL_FACTOR(CK_TOP_NET1_D8_D4, "net1_d8_d4", CK_APMIXED_NET1PLL, 1, 32),
+ PLL_FACTOR(CK_TOP_CB_NET2_800M, "cb_net2_800m", CK_APMIXED_NET2PLL, 1,
+ 1),
+ PLL_FACTOR(CK_TOP_CB_NET2_D2, "cb_net2_d2", CK_APMIXED_NET2PLL, 1, 2),
+ PLL_FACTOR(CK_TOP_CB_NET2_D4, "cb_net2_d4", CK_APMIXED_NET2PLL, 1, 4),
+ PLL_FACTOR(CK_TOP_NET2_D4_D2,
Re: [PATCH 25/31] clk: mediatek: add CLK_XTAL support for clock driver
On 8/3/22 11:36 PM, Weijie Gao wrote: This add CLK_XTAL macro and flag to mediatek clock driver common part, to make thi SoC that has clock directlly connect to XTAL working. nit: this.. directly But I'm having trouble reading your commit message. Perhaps something like This adds the CLK_XTAL macro/flag to allow modeling clocks which are directly connected to a fixed-rate clock. Signed-off-by: Weijie Gao --- drivers/clk/mediatek/clk-mtk.c | 3 +++ drivers/clk/mediatek/clk-mtk.h | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c index be3846c85b..5a4650d137 100644 --- a/drivers/clk/mediatek/clk-mtk.c +++ b/drivers/clk/mediatek/clk-mtk.c @@ -296,6 +296,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk *clk, u32 off) rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL); break; + case CLK_PARENT_XTAL: default: rate = priv->tree->xtal_rate; } @@ -314,6 +315,8 @@ static ulong mtk_infrasys_get_factor_rate(struct clk *clk, u32 off) rate = mtk_clk_find_parent_rate(clk, fdiv->parent, priv->parent); break; + case CLK_PARENT_XTAL: + rate = priv->tree->xtal_rate; default: rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL); } diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h index 8536275671..211356697b 100644 --- a/drivers/clk/mediatek/clk-mtk.h +++ b/drivers/clk/mediatek/clk-mtk.h @@ -26,7 +26,8 @@ #define CLK_PARENT_APMIXEDBIT(4) #define CLK_PARENT_TOPCKGEN BIT(5) #define CLK_PARENT_INFRASYS BIT(6) -#define CLK_PARENT_MASKGENMASK(6, 4) +#define CLK_PARENT_XTALBIT(7) +#define CLK_PARENT_MASKGENMASK(7, 4) #define ETHSYS_HIFSYS_RST_CTRL_OFS 0x34
Re: [PATCH 24/31] clk: mediatek: add infrasys clock mux support
On 8/3/22 11:36 PM, Weijie Gao wrote:
This patch adds infrasys clock mux support for mediatek clock drivers.
Signed-off-by: Weijie Gao
---
drivers/clk/mediatek/clk-mtk.c | 72 ++
drivers/clk/mediatek/clk-mtk.h | 4 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 908ed2b4ba..be3846c85b 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -303,6 +303,24 @@ static ulong mtk_topckgen_get_factor_rate(struct clk
*clk, u32 off)
return mtk_factor_recalc_rate(fdiv, rate);
}
+static ulong mtk_infrasys_get_factor_rate(struct clk *clk, u32 off)
+{
+ struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+ const struct mtk_fixed_factor *fdiv = >tree->fdivs[off];
+ ulong rate;
+
+ switch (fdiv->flags & CLK_PARENT_MASK) {
+ case CLK_PARENT_TOPCKGEN:
+ rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
+ priv->parent);
+ break;
+ default:
+ rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
+ }
+
+ return mtk_factor_recalc_rate(fdiv, rate);
+}
+
static ulong mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -332,6 +350,34 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
u32 off)
return priv->tree->xtal_rate;
}
+static ulong mtk_infrasys_get_mux_rate(struct clk *clk, u32 off)
+{
+ struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+ const struct mtk_composite *mux = >tree->muxes[off];
+ u32 index;
+ u32 flag;
+
+ index = readl(priv->base + mux->mux_reg);
+ index &= mux->mux_mask << mux->mux_shift;
+ index = index >> mux->mux_shift;
+
+ if (mux->parent[index] == CLK_XTAL && priv->tree->flags &
CLK_BYPASS_XTAL)
+ flag = 1;
+ if (mux->parent[index] > 0 || flag == 1) {
Please just use the condition directly
+ switch (mux->flags & CLK_PARENT_MASK) {
+ case CLK_PARENT_TOPCKGEN:
+ return mtk_clk_find_parent_rate(clk, mux->parent[index],
+ priv->parent);
+ break;
+ default:
+ return mtk_clk_find_parent_rate(clk, mux->parent[index],
+ NULL);
+ break;
+ }
+ }
+ return 0;
+}
+
static ulong mtk_topckgen_get_rate(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -346,6 +392,25 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
priv->tree->muxes_offs);
}
+static ulong mtk_infrasys_get_rate(struct clk *clk)
+{
+ struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
+
+ ulong rate;
+
+ if (clk->id < priv->tree->fdivs_offs) {
+ rate = priv->tree->fclks[clk->id].rate;
+ } else if (clk->id < priv->tree->muxes_offs) {
+ rate = mtk_infrasys_get_factor_rate(clk, clk->id -
+ priv->tree->fdivs_offs);
+ } else {
+ rate = mtk_infrasys_get_mux_rate(clk, clk->id -
+priv->tree->muxes_offs);
+ }
+
+ return rate;
+}
+
static int mtk_clk_mux_enable(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -494,6 +559,13 @@ const struct clk_ops mtk_clk_topckgen_ops = {
.set_parent = mtk_common_clk_set_parent,
};
+const struct clk_ops mtk_clk_infrasys_ops = {
+ .enable = mtk_clk_mux_enable,
+ .disable = mtk_clk_mux_disable,
+ .get_rate = mtk_infrasys_get_rate,
+ .set_parent = mtk_common_clk_set_parent,
+};
+
const struct clk_ops mtk_clk_gate_ops = {
.enable = mtk_clk_gate_enable,
.disable = mtk_clk_gate_disable,
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 7955d469db..8536275671 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,7 +25,8 @@
#define CLK_PARENT_APMIXED BIT(4)
#define CLK_PARENT_TOPCKGEN BIT(5)
-#define CLK_PARENT_MASKGENMASK(5, 4)
+#define CLK_PARENT_INFRASYSBIT(6)
+#define CLK_PARENT_MASKGENMASK(6, 4)
#define ETHSYS_HIFSYS_RST_CTRL_OFS 0x34
@@ -217,6 +218,7 @@ struct mtk_cg_priv {
extern const struct clk_ops mtk_clk_apmixedsys_ops;
extern const struct clk_ops mtk_clk_topckgen_ops;
+extern const struct clk_ops mtk_clk_infrasys_ops;
extern const struct clk_ops mtk_clk_gate_ops;
int mtk_common_clk_init(struct udevice *dev,
Re: [PATCH 23/31] clk: mediatek: add support to configure clock driver parent
On 8/3/22 11:36 PM, Weijie Gao wrote:
This patch adds support for a clock node to configure its parent clock
where possible.
Signed-off-by: Weijie Gao
---
drivers/clk/mediatek/clk-mtk.c | 79 --
drivers/clk/mediatek/clk-mtk.h | 2 +
2 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index d99ea55df0..908ed2b4ba 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -42,20 +42,14 @@
* the accurate frequency.
*/
static ulong mtk_clk_find_parent_rate(struct clk *clk, int id,
- const struct driver *drv)
+ struct udevice *pdev)
{
struct clk parent = { .id = id, };
- if (drv) {
- struct udevice *dev;
-
- if (uclass_get_device_by_driver(UCLASS_CLK, drv, ))
- return -ENODEV;
-
- parent.dev = dev;
- } else {
+ if (pdev)
+ parent.dev = pdev;
+ else
parent.dev = clk->dev;
- }
return clk_get_rate();
You must call clk_request(parent) before calling clk_get_rate.
}
@@ -296,7 +290,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk
*clk, u32 off)
switch (fdiv->flags & CLK_PARENT_MASK) {
case CLK_PARENT_APMIXED:
rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
- DM_DRIVER_GET(mtk_clk_apmixedsys));
+ priv->parent);
break;
case CLK_PARENT_TOPCKGEN:
rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
@@ -322,9 +316,18 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
u32 off)
if (mux->parent[index] == CLK_XTAL && priv->tree->flags & CLK_BYPASS_XTAL)
flag = 1;
- if (mux->parent[index] > 0 || flag == 1)
- return mtk_clk_find_parent_rate(clk, mux->parent[index],
- NULL);
+ if (mux->parent[index] > 0 || flag == 1) {
+ switch (mux->flags & CLK_PARENT_MASK) {
+ case CLK_PARENT_APMIXED:
+ return mtk_clk_find_parent_rate(clk, mux->parent[index],
+ priv->parent);
+ break;
+ default:
+ return mtk_clk_find_parent_rate(clk, mux->parent[index],
+ NULL);
+ break;
+ }
+ }
return priv->tree->xtal_rate;
}
@@ -343,7 +346,7 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
priv->tree->muxes_offs);
}
-static int mtk_topckgen_enable(struct clk *clk)
+static int mtk_clk_mux_enable(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_composite *mux;
@@ -376,7 +379,7 @@ static int mtk_topckgen_enable(struct clk *clk)
return 0;
}
-static int mtk_topckgen_disable(struct clk *clk)
+static int mtk_clk_mux_disable(struct clk *clk)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_composite *mux;
@@ -402,7 +405,7 @@ static int mtk_topckgen_disable(struct clk *clk)
return 0;
}
-static int mtk_topckgen_set_parent(struct clk *clk, struct clk *parent)
+static int mtk_common_clk_set_parent(struct clk *clk, struct clk *parent)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
@@ -474,19 +477,7 @@ static ulong mtk_clk_gate_get_rate(struct clk *clk)
struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
const struct mtk_gate *gate = >gates[clk->id];
- switch (gate->flags & CLK_PARENT_MASK) {
- case CLK_PARENT_APMIXED:
- return mtk_clk_find_parent_rate(clk, gate->parent,
- DM_DRIVER_GET(mtk_clk_apmixedsys));
- break;
- case CLK_PARENT_TOPCKGEN:
- return mtk_clk_find_parent_rate(clk, gate->parent,
- DM_DRIVER_GET(mtk_clk_topckgen));
- break;
-
- default:
- return priv->tree->xtal_rate;
- }
+ return mtk_clk_find_parent_rate(clk, gate->parent, priv->parent);
}
const struct clk_ops mtk_clk_apmixedsys_ops = {
@@ -497,10 +488,10 @@ const struct clk_ops mtk_clk_apmixedsys_ops = {
};
const struct clk_ops mtk_clk_topckgen_ops = {
- .enable = mtk_topckgen_enable,
- .disable = mtk_topckgen_disable,
+ .enable = mtk_clk_mux_enable,
+ .disable = mtk_clk_mux_disable,
.get_rate = mtk_topckgen_get_rate,
- .set_parent = mtk_topckgen_set_parent,
+ .set_parent = mtk_common_clk_set_parent,
};
const struct clk_ops mtk_clk_gate_ops = {
@@ -513,11 +504,22 @@
Re: [RESEND PATCH v2] clk: update clk_clean_rate_cache to use private clk struct
Hi Patrick,
Sorry for the (very late) response.
On 7/12/22 8:24 AM, Patrick Delaunay wrote:
In clk_clean_rate_cache, clk->rate should update the private clock
struct, in particular when CCF is activated, to save the cached
rate value.
When clk_get_parent_rate is called, the cached information
is read from pclk->rate, with pclk = clk_get_parent(clk).
As the cached is read from private clk data, the update should
be done also on it.
Fixes: 6b7fd3128f7 ("clk: fix set_rate to clean up cached rates for the
hierarchy")
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- set *clkp = clk when CCF is not activated and when the clock is not found
drivers/clk/clk-uclass.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index b89c77bf794..5cfa022a6dc 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -544,6 +544,19 @@ ulong clk_round_rate(struct clk *clk, ulong rate)
return ops->round_rate(clk, rate);
}
+static void clk_get_priv(struct clk *clk, struct clk **clkp)
+{
+ *clkp = clk;
+
+ /* get private clock struct associated to the provided clock */
+ if (CONFIG_IS_ENABLED(CLK_CCF)) {
+ /* Take id 0 as a non-valid clk, such as dummy */
+ if (clk->id)
+ clk_get_by_id(clk->id, clkp);
+ }
+}
+
+/* clean cache, called with private clock struct */
static void clk_clean_rate_cache(struct clk *clk)
{
struct udevice *child_dev;
@@ -563,6 +576,7 @@ static void clk_clean_rate_cache(struct clk *clk)
ulong clk_set_rate(struct clk *clk, ulong rate)
{
const struct clk_ops *ops;
+ struct clk *clkp;
debug("%s(clk=%p, rate=%lu)\n", __func__, clk, rate);
if (!clk_valid(clk))
@@ -572,8 +586,10 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
if (!ops->set_rate)
return -ENOSYS;
+ /* get private clock struct used for cache */
+ clk_get_priv(clk, );
/* Clean up cached rates for us and all child clocks */
- clk_clean_rate_cache(clk);
+ clk_clean_rate_cache(clkp);
return ops->set_rate(clk, rate);
}
Reviewed-by: Sean Anderson
Re: binman warning/failure when blobs are missing
Hi Tom, On Fri, 12 Aug 2022 at 10:11, Tom Rini wrote: > > On Fri, Aug 12, 2022 at 09:11:11AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 11 Aug 2022 at 19:03, Tom Rini wrote: > > > > > > On Thu, Aug 11, 2022 at 06:08:51PM -0600, Simon Glass wrote: > > > > Hi, > > > > > > > > On Thu, 11 Aug 2022 at 11:44, Tom Rini wrote: > > > > > > > > > > On Thu, Aug 11, 2022 at 09:59:05AM -0700, Tim Harvey wrote: > > > > > > On Thu, Aug 11, 2022 at 9:48 AM Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Aug 11, 2022 at 09:27:44AM -0700, Tim Harvey wrote: > > > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > After a couple of hours troubleshooting a bad boot image today I > > > > > > > > realized the issue was that I had some 0 byte files for the > > > > > > > > lpddr4 > > > > > > > > training blobs that are part of the imx8mp binman created image. > > > > > > > > > > > > > > > > Digging in I found that if a blob referenced in the binman node > > > > > > > > is > > > > > > > > missing a warning will be output but the missing files will be > > > > > > > > 'created' as 0 byte files such that the next time you build you > > > > > > > > will > > > > > > > > get no warning (but will have a non-working image). > > > > > > > > Additionally the > > > > > > > > error does not cause a non-zero exit code. > > > > > > > > > > > > > > > > I'm not that fluent in python these days, and don't have the > > > > > > > > time for > > > > > > > > a while to try and fix this but I figured I would at least send > > > > > > > > this > > > > > > > > email in case someone else does. > > > > > > > > > > > > > > > > Example: > > > > > > > > # rm *lpddr4*.bin # make sure lpddr4*.bin files referenced in > > > > > > > > binman > > > > > > > > nodes are missing > > > > > > > > # make distclean imx8mp_venice_defconfig flash.bin && echo > > > > > > > > "build ok" > > > > > > > > ... > > > > > > > > BINMAN flash.bin > > > > > > > > Image 'main-section' is missing external blobs and is > > > > > > > > non-functional: ddr-1d-ime > > > > > > > > m-fw ddr-1d-dmem-fw ddr-2d-imem-fw ddr-2d-dmem-fw > > > > > > > > Image 'main-section' has faked external blobs and is > > > > > > > > non-functional: lpddr4_pmu_ > > > > > > > > train_1d_imem_202006.bin lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > > > lpddr4_pmu_train_2d > > > > > > > > _imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > > > > > > > > > > > Some images are invalid > > > > > > > > ^^^ excellent warning > > > > > > > > build ok > > > > > > > > ^^^ not so great that there is a successful exit code > > > > > > > > # make flash.bin && echo "build ok" > > > > > > > > ... > > > > > > > > BINMAN flash.bin > > > > > > > > build ok > > > > > > > > ^^^ absolutely horrible that 0 byte files were created and thus > > > > > > > > everything looks good this time around! > > > > > > > > # stat -c "%s %n" lpddr4*.bin > > > > > > > > 0 lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > > > 0 lpddr4_pmu_train_1d_imem_202006.bin > > > > > > > > 0 lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > > > 0 lpddr4_pmu_train_2d_imem_202006.bin > > > > > > > > > > > > > > So, this isn't the first time someone has had this problem. On > > > > > > > the one > > > > > > > hand, we need CI to pass, and not require fetching of arbitrary > > > > > > > further > > > > > > > images to assemble the binary. On the other hand, we don't want > > > > > > > users > > > > > > > spending a bunch of time because something didn't work and the > > > > > > > normal > > > > > > > way of conveying THIS WON'T WORK is a non-zero exit status. Can we > > > > > > > easily make some flag for buildman or binman that we do set in CI > > > > > > > but > > > > > > > won't be set by users? > > > > > > > > > > > > > > > > > > > Tom, > > > > > > > > > > > > Ok - that makes sense as far as the exit status goes. It would be > > > > > > MUCH > > > > > > easier to catch an error like this if binman didn't create 0 byte > > > > > > files for missing files so that you at least get the (ascii colored) > > > > > > message indicating the image is wrong. > > > > > > > > Please see this: > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220807154708.1418967-2-...@chromium.org/ > > > > > > > > > > > > > > > > I do love the idea of a flag for CI also! > > > > > > > > > > So, that's part of the root of the problem here. We're passing > > > > > --fake-ext-blobs to binman so that it will create those 0 byte files > > > > > and it in turn complain. I think we didn't figure out a good way to > > > > > tell buildman to pass that to binman tho? > > > > > > > > I hope the above patch will fix this part of the problem. > > > > > > I'm not sure. What I really want to see is something like buildman > > > --fake-ext-blobs, which in turn does 'make BINMANFLAGS=--fake-ext-blobs' > > > or 'make BINMAN_FAKE_EXT_BLOBS=1' and that is what sets --fake-ext-blobs > > > to be passed inside of cmd_binman, so
Re: [PATCH v2] bootstage: Show func name for bootstage_mark/error
Hi Michal,
On Fri, 12 Aug 2022 at 02:55, Michal Simek wrote:
>
> bootstage_mark() and bootstate_error() are not recording any name and in
> report it is showing as id=. That's not useful and it is better to
> show function name which calls it.
> That's why use macros with passing __func__ as recorded name for bootstage.
>
> Origin report looks like this:
> ZynqMP> bootstage report
> Timer summary in microseconds (10 records):
>MarkElapsed Stage
> 0 0 reset
> 2,482,383 2,482,383 board_init_f
> 4,278,821 1,796,438 board_init_r
> 4,825,331546,510 id=64
> 4,858,409 33,078 id=65
> 4,862,382 3,973 main_loop
> 4,921,713 59,331 usb_start
> 9,345,345 4,423,632 id=175
>
> When this patch is applied.
> ZynqMP> bootstage report
> Timer summary in microseconds (31 records):
>MarkElapsed Stage
> 0 0 reset
> 2,465,624 2,465,624 board_init_f
> 4,278,628 1,813,004 board_init_r
> 4,825,139546,511 eth_common_init
> 4,858,228 33,089 eth_initialize
> 4,862,201 3,973 main_loop
> 4,921,530 59,329 usb_start
> 8,885,334 3,963,804 cli_loop
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Add kernel-doc description
>
> common/bootstage.c | 10 ++
> include/bootstage.h | 21 ++---
> 2 files changed, 20 insertions(+), 11 deletions(-)
I can see what is going on here after applying it.
Reviewed-by: Simon Glass
But I think it would be better as inline functions rather than #define
>
> diff --git a/common/bootstage.c b/common/bootstage.c
> index 0fd33be97eae..326c40f1561f 100644
> --- a/common/bootstage.c
> +++ b/common/bootstage.c
> @@ -147,15 +147,9 @@ ulong bootstage_add_record(enum bootstage_id id, const
> char *name,
> return mark;
> }
>
> -
> -ulong bootstage_mark(enum bootstage_id id)
> -{
> - return bootstage_add_record(id, NULL, 0, timer_get_boot_us());
> -}
> -
> -ulong bootstage_error(enum bootstage_id id)
> +ulong bootstage_error_name(enum bootstage_id id, const char *name)
> {
> - return bootstage_add_record(id, NULL, BOOTSTAGEF_ERROR,
> + return bootstage_add_record(id, name, BOOTSTAGEF_ERROR,
> timer_get_boot_us());
> }
>
> diff --git a/include/bootstage.h b/include/bootstage.h
> index bca9438418f5..7088d0b875e4 100644
> --- a/include/bootstage.h
> +++ b/include/bootstage.h
> @@ -268,12 +268,27 @@ ulong bootstage_add_record(enum bootstage_id id, const
> char *name,
> /**
> * Mark a time stamp for the current boot stage.
> */
> -ulong bootstage_mark(enum bootstage_id id);
> -
> -ulong bootstage_error(enum bootstage_id id);
> +#define bootstage_mark(id) bootstage_mark_name(id, __func__)
> +#define bootstage_error(id)bootstage_error_name(id, __func__)
>
> +/**
> + * bootstage_mark_name - record bootstage with passing id and name
> + * @id: Bootstage id to record this timestamp against
> + * @name: Textual name to display for this id in the report
> + *
> + * Return: recorded time stamp
> + */
> ulong bootstage_mark_name(enum bootstage_id id, const char *name);
>
> +/**
> + * bootstage_error_name - record bootstage error with passing id and name
> + * @id: Bootstage id to record this timestamp against
> + * @name: Textual name to display for this id in the report
> + *
> + * Return: recorded time stamp
> + */
> +ulong bootstage_error_name(enum bootstage_id id, const char *name);
> +
> /**
> * Mark a time stamp in the given function and line number
> *
> --
> 2.36.1
>
Regards,
Simon
Re: [PATCH v3 3/4] arm_ffa: introduce Arm FF-A low-level driver
Hi Abdellatif,
On Mon, 1 Aug 2022 at 11:21, Abdellatif El Khlifi
wrote:
>
> Add the driver implementing Arm Firmware Framework for Armv8-A v1.0
>
> The Firmware Framework for Arm A-profile processors (FF-A)
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
>
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
>
> 32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP
> and FFA_MSG_SEND_DIRECT_{REQ, RESP}.
>
> In u-boot FF-A design, FF-A is considered as a discoverable bus.
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
>
> The driver exports its operations to be used by upper layers.
>
> Exported operations:
>
> - partition_info_get
> - sync_send_receive
> - rxtx_unmap
>
> This implementation provides an optional feature to copy the driver data
> to EFI runtime area.
This is v2 but I don't see a change list?
>
> Signed-off-by: Abdellatif El Khlifi
> Cc: Tom Rini
> Cc: Ilias Apalodimas
> Cc: Jens Wiklander
> ---
> MAINTAINERS|6 +
> common/board_r.c |7 +
> drivers/Kconfig|2 +
> drivers/Makefile |1 +
> drivers/arm-ffa/Kconfig| 33 +
> drivers/arm-ffa/Makefile |7 +
> drivers/arm-ffa/arm-ffa-uclass.c | 16 +
> drivers/arm-ffa/arm_ffa_prv.h | 219
> drivers/arm-ffa/core.c | 1338
> drivers/arm-ffa/efi_ffa_runtime_data_mgr.c | 94 ++
> include/arm_ffa.h | 132 ++
> include/dm/uclass-id.h |1 +
> include/uuid.h |8 +
> lib/efi_loader/efi_boottime.c | 17 +
> lib/uuid.c | 65 +
> 15 files changed, 1946 insertions(+)
> create mode 100644 drivers/arm-ffa/Kconfig
> create mode 100644 drivers/arm-ffa/Makefile
> create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c
> create mode 100644 drivers/arm-ffa/arm_ffa_prv.h
> create mode 100644 drivers/arm-ffa/core.c
> create mode 100644 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c
> create mode 100644 include/arm_ffa.h
>
I think this should be in an existing directory, or perhaps drivers/firmware.
Regards,
Simon
Re: [PATCH v2 2/6] console: Implement flush() function
Hi Pali,
On Fri, 12 Aug 2022 at 09:17, Pali Rohár wrote:
>
> On Friday 12 August 2022 09:11:10 Simon Glass wrote:
> > Hi Pali,
> >
> > On Fri, 12 Aug 2022 at 03:01, Pali Rohár wrote:
> > >
> > > On Thursday 11 August 2022 18:08:46 Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Thu, 11 Aug 2022 at 08:50, Pali Rohár wrote:
> > > > >
> > > > > On Thursday 11 August 2022 08:47:50 Simon Glass wrote:
> > > > > > > diff --git a/include/stdio_dev.h b/include/stdio_dev.h
> > > > > > > index 270fa2729fb2..06278366ae88 100644
> > > > > > > --- a/include/stdio_dev.h
> > > > > > > +++ b/include/stdio_dev.h
> > > > > > > @@ -37,6 +37,10 @@ struct stdio_dev {
> > > > > > > void (*putc)(struct stdio_dev *dev, const char c);
> > > > > > > /* To put a string (accelerator) */
> > > > > > > void (*puts)(struct stdio_dev *dev, const char *s);
> > > > > > > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > > > > >
> > > > > > I'd argue it isn't worth the #ifdef and we might as well have this
> > > > > > member here always. Then you can drop some #ifdefs from your code.
> > > > >
> > > > > But then it will increase binary code size.
> > > >
> > > > Using the member will increase code size. But I think the only place
> > > > you need an #ifdef for that is when you include it in the driver
> > > > struct. You can use __maybe_unused in the other place.
> > > >
> > > > Having the member will only increase memory usage, not code size.
> > >
> > > But static memory structures are part of the u-boot.bin binary and also
> > > their usage increase code size (required copy, etc...), so at the end it
> > > increase code size.
> >
> > From what I understand stdio_dev is allocated at runtime in BSS:
> >
> > struct stdio_dev *stdio_devices[] = { NULL, NULL, NULL };
> >
> > (the NULL stuff should not be there, but does nothing, I believe)
> >
> > So long as no code accesses your new member, then it should only
> > affect the BSS size.
>
> Code of course has to access new member. How otherwise would be able to
> call that new callbacks? E.g. all new code in patch 2/6 or 3/6.
Yes, see below. Also, do check whether it actually adds code or not.
>
> > If you are very worried about it, you could use the technique in
> > asm-generic/global_data.h to avoid #ifdefs in the C code:
> >
> > #ifdef CONFIG_GENERATE_ACPI_TABLE
> > #define gd_acpi_start() gd->acpi_start
> > #define gd_set_acpi_start(addr) gd->acpi_start = addr
> > #else
> > #define gd_acpi_start() 0UL
> > #define gd_set_acpi_start(addr)
> > #endif
> >
> > Regards,
> > Simon
Regards,
Simon
Re: [PATCH 8/8] Convert CONFIG_SYS_FSL_QMAN_V3 et al to Kconfig
On Sun, Jul 31, 2022 at 09:08:29PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_FSL_NGPIXIS >CONFIG_SYS_FSL_QMAN_V3 >CONFIG_SYS_FSL_RAID_ENGINE >CONFIG_SYS_FSL_RMU >CONFIG_SYS_FSL_SINGLE_SOURCE_CLK >CONFIG_SYS_FSL_SRIO_LIODN >CONFIG_SYS_FSL_TBCLK_DIV >CONFIG_SYS_FSL_USB1_PHY_ENABLE >CONFIG_SYS_FSL_USB2_PHY_ENABLE >CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE >CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/8] Convert CONFIG_SYS_FSL_PCIE_COMPAT to Kconfig
On Sun, Jul 31, 2022 at 09:08:28PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FSL_PCIE_COMPAT > > To do this, introduce a choice and option for each of the strings used > and set CONFIG_SYS_FSL_PCIE_COMPAT based on that. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/8] Convert CONFIG_SYS_FSL_NUM_CC_PLLS to Kconfig
On Sun, Jul 31, 2022 at 09:08:27PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FSL_NUM_CC_PLLS > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/8] Convert CONFIG_SYS_FSL_MAX_NUM_OF_SEC to Kconfig
On Sun, Jul 31, 2022 at 09:08:26PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FSL_MAX_NUM_OF_SEC > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/8] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE to Kconfig
On Sun, Jul 31, 2022 at 09:08:25PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/8] Remove CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR et al
On Sun, Jul 31, 2022 at 09:08:24PM -0400, Tom Rini wrote: > This removes the following symbols: >CONFIG_SYS_FSL_DSPI_BE >CONFIG_SYS_FSL_DSP_CCSRBAR_DEFAULT >CONFIG_SYS_FSL_DSP_CCSR_DDR_ADDR >CONFIG_SYS_FSL_DSP_CCSR_DDR_OFFSET >CONFIG_SYS_FSL_DSP_DDR_ADDR >CONFIG_SYS_FSL_DSP_M2_RAM_ADDR >CONFIG_SYS_FSL_DSP_M3_RAM_ADDR >CONFIG_SYS_FSL_ERRATUM_A008751 >CONFIG_SYS_FSL_ESDHC_BROKEN_TIMEOUT >CONFIG_SYS_FSL_ESDHC_NUM >CONFIG_SYS_FSL_ESDHC_P1010_BROKEN_SDCLK >CONFIG_SYS_FSL_FM1_RX0_1G_OFFSET >CONFIG_SYS_FSL_FM1_RX1_1G_OFFSET >CONFIG_SYS_FSL_FM1_RX2_1G_OFFSET >CONFIG_SYS_FSL_FM1_RX3_1G_OFFSET >CONFIG_SYS_FSL_FM1_RX4_1G_OFFSET >CONFIG_SYS_FSL_FM1_RX5_1G_OFFSET >CONFIG_SYS_FSL_ISBC_VER >CONFIG_SYS_FSL_QSPI_LE >CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR >CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET >CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET >CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR >CONFIG_SYS_FSL_SRDS_NUM_PLLS >CONFIG_SYS_FSL_WDOG_BE >CONFIG_SYS_GP1DIR >CONFIG_SYS_GP1ODR >CONFIG_SYS_GP2DIR >CONFIG_SYS_GP2ODR >CONFIG_SYS_HALT_BEFOR_RAM_JUMP >CONFIG_SYS_HMI_BASE >FSL_QSPI_FLASH_NUM >FSL_QSPI_FLASH_SIZE > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/8] arc: Move SYS_LITTLE_ENDIAN / SYS_BIG_ENDIAN selection to Kconfig
On Sun, Jul 31, 2022 at 09:08:23PM -0400, Tom Rini wrote: > We can determine which of these we need given CPU_BIG_ENDIAN being > enabled or not, so move that logic to Kconfig from config.mk. > > Cc: Alexey Brodkin > Cc: Eugeniy Paltsev > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/8] Convert CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS et al to Kconfig
On Sun, Jul 31, 2022 at 09:08:22PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS >CONFIG_SYS_FSL_OTHER_DDR_NUM_CTRLS > > And we remove the entries from the README for a number of already > converted items. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/21] ppc: Remove ids8313 board
On Tue, Aug 02, 2022 at 07:33:28AM -0400, Tom Rini wrote: > This board is behind on several mandatory DM migrations and is missing > OF_CONTROL support that makes other conversions impossible. Remove it. > > Cc: Heiko Schocher > Signed-off-by: Tom Rini > Acked-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/21] net: Remove smc91111 ethernet driver
On Tue, Aug 02, 2022 at 07:33:35AM -0400, Tom Rini wrote: > This driver has not been converted to DM_ETH. The migration deadline > passed 2 years ago. > > Cc: Linus Walleij > Cc: David Feng > Cc: Liviu Dudau > Cc: Andre Przywara > Signed-off-by: Tom Rini > Acked-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/21] arm: Remove snapper9260 board
On Tue, Aug 02, 2022 at 07:33:29AM -0400, Tom Rini wrote: > This board is behind on several mandatory DM migrations and is missing > OF_CONTROL support that makes other conversions impossible. Remove it. > > Cc: Simon Glass > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/21] Convert CONFIG_SYS_FDT_PAD to Kconfig
On Tue, Aug 02, 2022 at 07:33:27AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FDT_PAD > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: Azure: Move to Ubuntu 22.04 image
On Mon, Aug 08, 2022 at 10:44:45PM -0400, Tom Rini wrote: > As per https://github.com/actions/runner-images/issues/6002 the Ubuntu > 18.04 image is deprecated and will be removed by December 1, 2022. > Move to the Ubuntu 22.04 image as our base for launching our containers > from. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] CI: Azure: Move to using macOS-12 image
On Wed, Jul 27, 2022 at 11:10:24AM -0400, Tom Rini wrote: > As per https://github.com/actions/virtual-environments/issues/5583 the > macOS-10.15 image is being deprecated. Move us up to macOS-12. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/4] ARM: stm32: DH: Use common MAC address functions
On Tue, Jul 26, 2022 at 03:04:53PM +0200, Philip Oberfichtner wrote: > To reduce code duplication, let the stm32 based DH boards use the common > code for setting up their MAC addresses. > > Signed-off-by: Philip Oberfichtner > Tested-by: Marek Vasut > Reviewed-by: Marek Vasut > Reviewed-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/4] ARM: imx8: DH: Use common MAC address functions
On Tue, Jul 26, 2022 at 03:04:52PM +0200, Philip Oberfichtner wrote: > To reduce code duplication, let the imx8 based DH boards use the common > code for setting up their MAC addresses. > > Signed-off-by: Philip Oberfichtner > Tested-by: Marek Vasut > Reviewed-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/4] ARM: imx6: DH: Use common MAC address functions
On Tue, Jul 26, 2022 at 03:04:51PM +0200, Philip Oberfichtner wrote: > To reduce code duplication, let the imx6 based DH boards use the common > code for setting up their MAC addresses. > > Signed-off-by: Philip Oberfichtner > Tested-by: Marek Vasut > Reviewed-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] board: dhelectronics: Implement common MAC address functions
On Tue, Jul 26, 2022 at 03:04:50PM +0200, Philip Oberfichtner wrote: > This is a starting point for unifying duplicate code in the DH board > files. The functions for setting up MAC addresses are very similar for > the i.MX6, i.MX8 and stm32mp1 based boards. > > All pre-existing implementations follow the same logic: > > (1) Check if ethaddr is already set in the environment > (2) If not, try to get it from a board specific location (e.g. fuse) > (3) If not, try to get it from eeprom > > After this commit, (1) and (3) are implemented as common functions, > ready to be used by board specific files. > > Furthermore there is an implementation of (2) for imx based boards. > > Signed-off-by: Philip Oberfichtner > Reviewed-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 0/3] arm: bcmbca: move bcm68360 support under CONFIG_ARCH_BCMBCA
BCM68360 is a variant for the main PON chip BCM6856 which is part of the Broadcom BCA (Broadband Carrier Access origin) chipset family. BCM68360 was originally added by Philippe before Broadcom started to upstream the support for BCMBCA SoCs. The ARM based Broadband SoC family is now supported under the unified ARCH_BCMBCA config. This patch series migrate the BCM68360 support under the config of ARCH_BCMBCA and BCM6856. This patch series need to apply on top of my previous patch series [1]. [1] https://lists.denx.de/pipermail/u-boot/2022-August/491581.html William Zhang (3): arm: bcmbca: add bcm6856 SoC support under CONFIG_ARCH_BCMBCA arm: bcmbca: remove bcm68360 support under CONFIG_ARCH_BCM68360 arm: bcmbca: make bcm68360 driver depending on CONFIG_BCM6856 MAINTAINERS | 1 + arch/arm/Kconfig | 7 - arch/arm/dts/Makefile| 6 +- arch/arm/dts/bcm68360.dtsi | 217 --- arch/arm/dts/bcm6856.dtsi| 252 +++ arch/arm/dts/bcm968360bg.dts | 6 +- arch/arm/dts/bcm96856.dts| 30 +++ arch/arm/mach-bcmbca/Kconfig | 8 + arch/arm/mach-bcmbca/Makefile| 1 + arch/arm/mach-bcmbca/bcm6856/Kconfig | 17 ++ arch/arm/mach-bcmbca/bcm6856/Makefile| 5 + arch/arm/mach-bcmbca/bcm6856/mmu_table.c | 32 +++ board/broadcom/bcm968360bg/Kconfig | 17 -- board/broadcom/bcm968360bg/MAINTAINERS | 6 - board/broadcom/bcm968360bg/Makefile | 3 - board/broadcom/bcm968360bg/bcm968360bg.c | 62 -- board/broadcom/bcmbca/Kconfig| 7 + configs/bcm968360bg_ram_defconfig| 10 +- configs/bcm96856_defconfig | 23 +++ drivers/gpio/Kconfig | 2 +- drivers/led/Kconfig | 2 +- drivers/mtd/nand/raw/Kconfig | 2 +- drivers/spi/Kconfig | 2 +- drivers/watchdog/Kconfig | 2 +- include/configs/bcm96856.h | 15 ++ include/configs/broadcom_bcm968360bg.h | 32 --- 26 files changed, 407 insertions(+), 360 deletions(-) delete mode 100644 arch/arm/dts/bcm68360.dtsi create mode 100644 arch/arm/dts/bcm6856.dtsi create mode 100644 arch/arm/dts/bcm96856.dts create mode 100644 arch/arm/mach-bcmbca/bcm6856/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm6856/Makefile create mode 100644 arch/arm/mach-bcmbca/bcm6856/mmu_table.c delete mode 100644 board/broadcom/bcm968360bg/Kconfig delete mode 100644 board/broadcom/bcm968360bg/MAINTAINERS delete mode 100644 board/broadcom/bcm968360bg/Makefile delete mode 100644 board/broadcom/bcm968360bg/bcm968360bg.c create mode 100644 configs/bcm96856_defconfig create mode 100644 include/configs/bcm96856.h delete mode 100644 include/configs/broadcom_bcm968360bg.h -- 2.37.1 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH 3/3] arm: bcmbca: make bcm68360 driver depending on CONFIG_BCM6856
As CONFIG_ARCH_BCM68360 is replaced with CONFIG_BCM6856, update the driver Kconfig to use the new config symbol Signed-off-by: William Zhang --- drivers/gpio/Kconfig | 2 +- drivers/led/Kconfig | 2 +- drivers/mtd/nand/raw/Kconfig | 2 +- drivers/spi/Kconfig | 2 +- drivers/watchdog/Kconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 83f4f5089992..9e00b48234ab 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -110,7 +110,7 @@ config BCM2835_GPIO config BCM6345_GPIO bool "BCM6345 GPIO driver" - depends on DM_GPIO && (ARCH_BMIPS || ARCH_BCM68360 || \ + depends on DM_GPIO && (ARCH_BMIPS || BCM6856 || \ ARCH_BCM6858 || BCM63158 || \ ARCH_BCM6753) help diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig index d777414dda8d..bd8f23fd9631 100644 --- a/drivers/led/Kconfig +++ b/drivers/led/Kconfig @@ -37,7 +37,7 @@ config LED_BCM6753 config LED_BCM6858 bool "LED Support for BCM6858" - depends on LED && (ARCH_BCM68360 || ARCH_BCM6858 || BCM63158) + depends on LED && (BCM6856 || ARCH_BCM6858 || BCM63158) help This option enables support for LEDs connected to the BCM6858 HW has blinking capabilities and up to 32 LEDs can be controlled. diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 24c27b6ecf7f..5d006ca1ea07 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -103,7 +103,7 @@ config NAND_BRCMNAND_6753 config NAND_BRCMNAND_68360 bool "Support Broadcom NAND controller on bcm68360" - depends on NAND_BRCMNAND && ARCH_BCM68360 + depends on NAND_BRCMNAND && BCM6856 help Enable support for broadcom nand driver on bcm68360. diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 0a666eee80e7..978e5c86a420 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -91,7 +91,7 @@ config ATMEL_SPI config BCM63XX_HSSPI bool "BCM63XX HSSPI driver" - depends on (ARCH_BMIPS || ARCH_BCM68360 || \ + depends on (ARCH_BMIPS || BCM6856 || \ ARCH_BCM6858 || BCM63158) help Enable the BCM6328 HSSPI driver. This driver can be used to diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index ff4d1ee530d2..6d559515b78b 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -128,7 +128,7 @@ config WDT_AT91 config WDT_BCM6345 bool "BCM6345 watchdog timer support" - depends on WDT && (ARCH_BMIPS || ARCH_BCM68360 || \ + depends on WDT && (ARCH_BMIPS || BCM6856 || \ ARCH_BCM6858 || BCM63158 || \ ARCH_BCM6753) help -- 2.37.1 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH 2/3] arm: bcmbca: remove bcm68360 support under CONFIG_ARCH_BCM68360
BCM68360 is a variant within the BCM6856 chip family. Now that BCM6856
is supported under CONFIG_ARCH_BCMBCA and CONFIG_BCM6856, remove the
original ARCH_BCM68360 support and migrate its configuration and dts
settings. This includes:
- Remove the bcm968360bg board folder. It is replaced by the generic
bcmbca board folder.
- Merge the 68360.dtsi setting to the new 6856.dtsi file. Update board
dts with the new compatible string.
- Merge broadcom_bcm968360bg.h setting to the new bcm96856.h file.
Signed-off-by: William Zhang
---
arch/arm/Kconfig | 7 -
arch/arm/dts/Makefile| 6 +-
arch/arm/dts/bcm68360.dtsi | 217 ---
arch/arm/dts/bcm6856.dtsi| 149
arch/arm/dts/bcm968360bg.dts | 6 +-
board/broadcom/bcm968360bg/Kconfig | 17 --
board/broadcom/bcm968360bg/MAINTAINERS | 6 -
board/broadcom/bcm968360bg/Makefile | 3 -
board/broadcom/bcm968360bg/bcm968360bg.c | 62 ---
configs/bcm968360bg_ram_defconfig| 10 +-
include/configs/bcm96856.h | 4 +
include/configs/broadcom_bcm968360bg.h | 32
12 files changed, 163 insertions(+), 356 deletions(-)
delete mode 100644 arch/arm/dts/bcm68360.dtsi
delete mode 100644 board/broadcom/bcm968360bg/Kconfig
delete mode 100644 board/broadcom/bcm968360bg/MAINTAINERS
delete mode 100644 board/broadcom/bcm968360bg/Makefile
delete mode 100644 board/broadcom/bcm968360bg/bcm968360bg.c
delete mode 100644 include/configs/broadcom_bcm968360bg.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index da4defa08466..3f124ab0ce85 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -672,12 +672,6 @@ config ARCH_BCM6753
select OF_CONTROL
imply CMD_DM
-config ARCH_BCM68360
- bool "Broadcom BCM68360 family"
- select DM
- select OF_CONTROL
- imply CMD_DM
-
config ARCH_BCM6858
bool "Broadcom BCM6858 family"
select DM
@@ -2280,7 +2274,6 @@ source "board/armltd/vexpress/Kconfig"
source "board/armltd/vexpress64/Kconfig"
source "board/cortina/presidio-asic/Kconfig"
source "board/broadcom/bcm96753ref/Kconfig"
-source "board/broadcom/bcm968360bg/Kconfig"
source "board/broadcom/bcm968580xref/Kconfig"
source "board/broadcom/bcmns3/Kconfig"
source "board/cavium/thunderx/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a32bdf8c9f17..a0ea9fa6029d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1147,9 +1147,6 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2837-rpi-cm3-io3.dtb \
bcm2711-rpi-4-b.dtb
-dtb-$(CONFIG_ARCH_BCM68360) += \
- bcm968360bg.dtb
-
dtb-$(CONFIG_ARCH_BCM6753) += \
bcm96753ref.dtb
@@ -1183,7 +1180,8 @@ dtb-$(CONFIG_BCM6813) += \
dtb-$(CONFIG_BCM6846) += \
bcm96846.dtb
dtb-$(CONFIG_BCM6856) += \
- bcm96856.dtb
+ bcm96856.dtb \
+ bcm968360bg.dtb
dtb-$(CONFIG_BCM6878) += \
bcm96878.dtb
diff --git a/arch/arm/dts/bcm68360.dtsi b/arch/arm/dts/bcm68360.dtsi
deleted file mode 100644
index 7bbe207794eb..
--- a/arch/arm/dts/bcm68360.dtsi
+++ /dev/null
@@ -1,217 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2020 Philippe Reynes
- */
-
-#include "skeleton64.dtsi"
-
-/ {
- compatible = "brcm,bcm68360";
- #address-cells = <2>;
- #size-cells = <2>;
-
- aliases {
- spi0 =
- };
-
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
- u-boot,dm-pre-reloc;
-
- cpu0: cpu@0 {
- compatible = "arm,cortex-a53", "arm,armv8";
- device_type = "cpu";
- reg = <0x0 0x0>;
- next-level-cache = <>;
- u-boot,dm-pre-reloc;
- };
-
- cpu1: cpu@1 {
- compatible = "arm,cortex-a53", "arm,armv8";
- device_type = "cpu";
- reg = <0x0 0x1>;
- next-level-cache = <>;
- u-boot,dm-pre-reloc;
- };
-
- l2: l2-cache0 {
- compatible = "cache";
- u-boot,dm-pre-reloc;
- };
- };
-
- clocks {
- compatible = "simple-bus";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- u-boot,dm-pre-reloc;
-
- periph_osc: periph-osc {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <2>;
- u-boot,dm-pre-reloc;
- };
-
- hsspi_pll: hsspi-pll {
- compatible = "fixed-factor-clock";
- #clock-cells = <0>;
- clocks =
[PATCH 1/3] arm: bcmbca: add bcm6856 SoC support under CONFIG_ARCH_BCMBCA
BCM6856 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other Broadband
SoC, this patch adds it under CONFIG_BCM6856 chip config and
CONFIG_ARCH_BCMBCA platform config.
This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and Broadcom uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang
---
MAINTAINERS | 1 +
arch/arm/dts/Makefile| 2 +
arch/arm/dts/bcm6856.dtsi| 103 +++
arch/arm/dts/bcm96856.dts| 30 +++
arch/arm/mach-bcmbca/Kconfig | 8 ++
arch/arm/mach-bcmbca/Makefile| 1 +
arch/arm/mach-bcmbca/bcm6856/Kconfig | 17
arch/arm/mach-bcmbca/bcm6856/Makefile| 5 ++
arch/arm/mach-bcmbca/bcm6856/mmu_table.c | 32 +++
board/broadcom/bcmbca/Kconfig| 7 ++
configs/bcm96856_defconfig | 23 +
include/configs/bcm96856.h | 11 +++
12 files changed, 240 insertions(+)
create mode 100644 arch/arm/dts/bcm6856.dtsi
create mode 100644 arch/arm/dts/bcm96856.dts
create mode 100644 arch/arm/mach-bcmbca/bcm6856/Kconfig
create mode 100644 arch/arm/mach-bcmbca/bcm6856/Makefile
create mode 100644 arch/arm/mach-bcmbca/bcm6856/mmu_table.c
create mode 100644 configs/bcm96856_defconfig
create mode 100644 include/configs/bcm96856.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d0a5b2352cc8..1f50dad583ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -230,6 +230,7 @@ N: bcm[9]?63178
N: bcm[9]?6756
N: bcm[9]?6813
N: bcm[9]?6846
+N: bcm[9]?6856
N: bcm[9]?6878
ARM BROADCOM BCMSTB
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c55bc3569662..a32bdf8c9f17 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1182,6 +1182,8 @@ dtb-$(CONFIG_BCM6813) += \
bcm96813.dtb
dtb-$(CONFIG_BCM6846) += \
bcm96846.dtb
+dtb-$(CONFIG_BCM6856) += \
+ bcm96856.dtb
dtb-$(CONFIG_BCM6878) += \
bcm96878.dtb
diff --git a/arch/arm/dts/bcm6856.dtsi b/arch/arm/dts/bcm6856.dtsi
new file mode 100644
index ..0bce6497219f
--- /dev/null
+++ b/arch/arm/dts/bcm6856.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include
+#include
+
+/ {
+ compatible = "brcm,bcm6856", "brcm,bcmbca";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ interrupt-parent = <>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ B53_0: cpu@0 {
+ compatible = "brcm,brahma-b53";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ next-level-cache = <_0>;
+ enable-method = "psci";
+ };
+
+ B53_1: cpu@1 {
+ compatible = "brcm,brahma-b53";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ next-level-cache = <_0>;
+ enable-method = "psci";
+ };
+
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+ ,
+ ,
+ ;
+ };
+
+ pmu: pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+ ;
+ interrupt-affinity = <_0>, <_1>;
+ };
+
+ clocks: clocks {
+ periph_clk:periph-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ axi@8100 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x8100 0x8000>;
+
+ gic: interrupt-controller@1000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x1000 0x1000>, /* GICD */
+ <0x2000 0x2000>, /* GICC */
+ <0x4000 0x2000>, /* GICH */
+ <0x6000 0x2000>; /* GICV */
+ interrupts = ;
+ };
+ };
+
+ bus@ff80
Re: [RFC PATCH v4 26/28] for test purpose only: Comment out dollar tests which prints error messages.
Le vendredi 17 juin 2022, 16:02:35 CEST Tom Rini a écrit : > On Fri, Jun 17, 2022 at 12:31:56AM +0200, Francis Laniel wrote: > > Error messages like "unknown command" will make the CI fails. > > So, for the moment, we comment these tests. > > > > Signed-off-by: Francis Laniel > > Why don't we have the test expect "unknown command" as the output here, > when on the newer shell? Or if both shells print that now, in both > cases? We want tests for when things are expected to fail. If you run `ut hush` from U-Boot prompt, this test does not fail (I added the failure on purpose to test that it should fail). But when run from the CI, it is run within test.py which checks from "unknown command" to not be present in the output [1]. I am not really familiar with the python testing framework but I think I can find another solution using disable_check() when running this test with 2021 shell. --- [1] https://elixir.bootlin.com/u-boot/v2022.07/source/test/py/ u_boot_console_base.py#L35
Re: [RFC PATCH v4 28/28] board: keymile: common: Use environment to store IVM_* variables.
Hi.
Le lundi 20 juin 2022, 19:33:24 CEST Tom Rini a écrit :
> On Mon, Jun 20, 2022 at 04:08:32PM +, Holger Brunck wrote:
> > > > > On Fri, Jun 17, 2022 at 12:31:58AM +0200, Francis Laniel wrote:
> > > > > > These boards used set_local_var() to store some variables as local
> > > > > > shell.
> > > > > > They then used get_local_var() to retrieve the variables values.
> > > > > >
> > > > > > Instead of using local shell variables, they should use
> > > > > > environment ones (like a majority of board).
> > > > > > So, this patch converts using local variables to environment ones.
> > > >
> > > > why do we need to change that? It is intended that we use this hush
> > > > variable infrastructure from u-boot (common/hush.c) for our IVM data
> > > > and not the standard env. We read the IVM at boot time and store these
> > > > values in RAM. It is not intended to store them permanently in the
> > > > flash or wherever the environment is saved. Especially in our case we
> > > > have some boards where the environment is in a i2c EEPROM and we don't
> > > > want to write down to the EEPROM each time when the board is starting.
> > >
> > > So, the whole series is about updating hush to bring in a new baseline
> > > version of the shell, from busybox.
> >
> > Ok.
> >
> > > > > > Signed-off-by: Francis Laniel
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > board/keymile/common/common.c | 8
> > > > > > board/keymile/common/ivm.c| 9 +
> > > > > > 2 files changed, 5 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/board/keymile/common/common.c
> > > > > > b/board/keymile/common/common.c index 3999f48719..72939af36e
> > > > > > 100644
> > > > > > --- a/board/keymile/common/common.c
> > > > > > +++ b/board/keymile/common/common.c
> > > > > > @@ -219,7 +219,7 @@ static int do_setboardid(struct cmd_tbl
> > > > > > *cmdtp, int
> > > > >
> > > > > flag, int argc,
> > > > >
> > > > > > unsigned char buf[32];
> > > > > > char *p;
> > > > > >
> > > > > > - p = get_local_var("IVM_BoardId");
> > > > > > + p = env_get("IVM_BoardId");
> > > > > >
> > > > > > if (!p) {
> > > > > >
> > > > > > printf("can't get the IVM_Boardid\n");
> > > > > > return 1;
> > > > > >
> > > > > > @@ -228,7 +228,7 @@ static int do_setboardid(struct cmd_tbl
> > > > > > *cmdtp, int
> > > > >
> > > > > flag, int argc,
> > > > >
> > > > > > env_set("boardid", (char *)buf);
> > > > > > printf("set boardid=%s\n", buf);
> > > > > >
> > > > > > - p = get_local_var("IVM_HWKey");
> > > > > > + p = env_get("IVM_HWKey");
> > > > > >
> > > > > > if (!p) {
> > > > > >
> > > > > > printf("can't get the IVM_HWKey\n");
> > > > > > return 1;
> > > > > >
> > > > > > @@ -272,14 +272,14 @@ static int do_checkboardidhwk(struct cmd_tbl
> > > > >
> > > > > *cmdtp, int flag, int argc,
> > > > >
> > > > > > * first read out the real inventory values, these values are
> > > > > > * already stored in the local hush variables
> > > > > > */
> > > > > >
> > > > > > - p = get_local_var("IVM_BoardId");
> > > > > > + p = env_get("IVM_BoardId");
> > > > > >
> > > > > > if (!p) {
> > > > > >
> > > > > > printf("can't get the IVM_Boardid\n");
> > > > > > return 1;
> > > > > >
> > > > > > }
> > > > > > rc = strict_strtoul(p, 16, );
> > > > > >
> > > > > > - p = get_local_var("IVM_HWKey");
> > > > > > + p = env_get("IVM_HWKey");
> > > > > >
> > > > > > if (!p) {
> > > > > >
> > > > > > printf("can't get the IVM_HWKey\n");
> > > > > > return 1;
> > > > > >
> > > > > > diff --git a/board/keymile/common/ivm.c
> > > > > > b/board/keymile/common/ivm.c index 67db0c50f4..e266d7ce81 100644
> > > > > > --- a/board/keymile/common/ivm.c
> > > > > > +++ b/board/keymile/common/ivm.c
> > > > > > @@ -44,14 +44,7 @@ static int ivm_calc_crc(unsigned char *buf, int
> > > > > > len)
> > > > > >
> > > > > > static int ivm_set_value(char *name, char *value) {
> > > > > >
> > > > > > - char tempbuf[256];
> > > > > > -
> > > > > > - if (value) {
> > > > > > - sprintf(tempbuf, "%s=%s", name, value);
> > > > > > - return set_local_var(tempbuf, 0);
> > > > > > - }
> > > > > > - unset_local_var(name);
> > > > > > - return 0;
> > > > > > + return env_set(name, value);
> > > >
> > > > this means we are now writing always down to the permanent environment
> > > > or? And this I would really like to avoid in our case.
> > >
> > > Note that "env_set" does not force a save of the running environment.
> >
> > Ah yes you are right. But still for the first boot of our board we will
> > call saveenv to store an initial environment and with this change it
> > would also write down the IVM data which is currently only stored
> > temporary in RAM.
> >
> > > These variables will be exposed to the CLI run-time, which I am not
[PATCH] ARM: imx: dh-imx6: Increase SF erase area for u-boot update
Erase the entire U-Boot area during U-Boot update instead of just
a subset of it. This way, in case u-boot-with-spl.imx grows, the
sf write won't write over non-erased part of the SPI NOR.
Signed-off-by: Marek Vasut
---
Cc: Christoph Niedermaier
Cc: Fabio Estevam
Cc: Stefano Babic
---
include/configs/dh_imx6.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index 79424647f61..0f7e1c5c451 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -60,7 +60,7 @@
"fdtfile=imx6q-dhcom-pdk2.dtb\0"\
"update_sf=" /* Erase SPI NOR and install U-Boot from SD */ \
"load mmc 0:1 ${loadaddr} /boot/u-boot-with-spl.imx && "\
- "sf probe && sf erase 0x0 0xa && " \
+ "sf probe && sf erase 0x0 0x10 && " \
"sf write ${loadaddr} 0x400 ${filesize}\0" \
BOOTENV
--
2.35.1
Re: [RFC PATCH v4 25/28] cli: hush_2021: Add upstream commits up to 6th February 2022.
Hi.
Le lundi 20 juin 2022, 21:11:00 CEST Tom Rini a écrit :
> On Fri, Jun 17, 2022 at 12:31:55AM +0200, Francis Laniel wrote:
> > This commit adds the following hush busybox upstream commits:
> > 21afddefd258 ("hush: fix "error: invalid preprocessing directive ##"")
> > e53c7dbafc78 ("hush: fix set -n to act immediately, not just after
> > run_list() ")
> > 574b9c446da1 ("hush: fix var_LINENO3.tests failure")
> > 49bcf9f40cff ("hush: speed up ${x//\*/|} too")
> > 53b2fdcdba4c ("*: add NOINLINEs where code noticeably shrinks")
> > 7c3e96d4b3d4 ("shell: use more compact SHELL_ASH / HUSH config defines. no
> > code changes") 62f1eed1e191 ("hush: in a comment, document what -i might
> > be doing") aaf3d5ba74c5 ("shell: tweak --help")
> > db5546ca1018 ("libbb: code shrink: introduce and use [_]exit_SUCCESS()")
> > 931c55f9e2b4 ("libbb: invert the meaning of SETUP_ENV_NO_CHDIR ->
> > SETUP_ENV_CHDIR") 12566e7f9b5e ("ash,hush: fix handling of SIGINT while
> > waiting for interactive input") 987be932ed3c ("*: slap on a few ALIGN_PTR
> > where appropriate")
> >
> > Signed-off-by: Francis Laniel
>
> Oh good, this was added to the series. How much effort did it take you
> to do this? Do you think it would be sustainable to keep doing
> something like this once every U-Boot full release cycle, like say when
> -next opens up or just after release or similar?
Sorry for my late reply.
I was not so complicated to add these patches as they did not really touch
part we have in common.
I think it took me sometimes because I wanted to understand everything to
avoid breaking things.
I would rather advice doing this more often, something like once a month as
the less patches we will need to merge the easier it is.
[PATCH 7/7] ARM: dts: imx: Fix I2C5 GPIO assignment on i.MX8M Plus DHCOM
Fix copy-paste error of the I2C5 bus recovery GPIO assignment, the I2C5 GPIOs are on gpio3 instead of gpio5. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: uboot-imx --- arch/arm/dts/imx8mp-dhcom-som.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/imx8mp-dhcom-som.dtsi b/arch/arm/dts/imx8mp-dhcom-som.dtsi index 0960c238871..197840d1a6a 100644 --- a/arch/arm/dts/imx8mp-dhcom-som.dtsi +++ b/arch/arm/dts/imx8mp-dhcom-som.dtsi @@ -415,8 +415,8 @@ pinctrl-names = "default", "gpio"; pinctrl-0 = <_i2c5>; pinctrl-1 = <_i2c5_gpio>; - scl-gpios = < 26 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; - sda-gpios = < 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + scl-gpios = < 26 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = < 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "okay"; }; -- 2.35.1
[PATCH 6/7] ARM: dts: imx: Adjust ECSPI1 pinmux on i.MX8M Plus DHCOM
The ECSPI1 is on I2C1/I2C2 pins of the SoC, update the pinmux accordingly.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: uboot-imx
---
arch/arm/dts/imx8mp-dhcom-som.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-som.dtsi
b/arch/arm/dts/imx8mp-dhcom-som.dtsi
index 63cc6c92c41..0960c238871 100644
--- a/arch/arm/dts/imx8mp-dhcom-som.dtsi
+++ b/arch/arm/dts/imx8mp-dhcom-som.dtsi
@@ -70,7 +70,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_ecspi1>;
- cs-gpios = < 9 GPIO_ACTIVE_LOW>;
+ cs-gpios = < 17 GPIO_ACTIVE_LOW>;
status = "disabled";
};
@@ -660,10 +660,10 @@
pinctrl_ecspi1: dhcom-ecspi1-grp {
fsl,pins = <
- MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x44
- MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x44
- MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x44
- MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x40
+ MX8MP_IOMUXC_I2C1_SCL__ECSPI1_SCLK 0x44
+ MX8MP_IOMUXC_I2C1_SDA__ECSPI1_MOSI 0x44
+ MX8MP_IOMUXC_I2C2_SCL__ECSPI1_MISO 0x44
+ MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x40
>;
};
--
2.35.1
[PATCH 3/7] ARM: dts: imx: Drop Atheros PHY header from i.MX8M Plus DHCOM PDK2
This PHY is not used on PDK2, the header was added due to copy-paste error, drop it. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: uboot-imx --- arch/arm/dts/imx8mp-dhcom-pdk2.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2.dts b/arch/arm/dts/imx8mp-dhcom-pdk2.dts index 7148234a4f1..0fcead35879 100644 --- a/arch/arm/dts/imx8mp-dhcom-pdk2.dts +++ b/arch/arm/dts/imx8mp-dhcom-pdk2.dts @@ -11,7 +11,6 @@ /dts-v1/; #include -#include #include #include "imx8mp-dhcom-som.dtsi" -- 2.35.1
[PATCH 5/7] ARM: dts: imx: Rename imx8mp-dhcom{-pdk2,}-boot.dtsi
Rename imx8mp-dhcom-pdk2-u-boot.dtsi to imx8mp-dhcom-u-boot.dtsi, since
this file is shared by PDK2, PicoITX and DRC02. No functional change.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: uboot-imx
---
arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi | 137 +---
arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 141 +
2 files changed, 142 insertions(+), 136 deletions(-)
create mode 100644 arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
index ae838caebcf..be2d4fb184a 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
@@ -3,139 +3,4 @@
* Copyright (C) 2022 Marek Vasut
*/
-#include "imx8mp-u-boot.dtsi"
-
-/ {
- aliases {
- eeprom0 =
- eeprom1 =
- mmc0 = /* MicroSD */
- mmc1 = /* eMMC */
- mmc2 = /* SDIO */
- };
-
- config {
- dh,ram-coding-gpios = < 22 0>, < 23 0>, < 24
0>;
- };
-
- wdt-reboot {
- compatible = "wdt-reboot";
- wdt = <>;
- u-boot,dm-spl;
- };
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
-_i2c3 {
- u-boot,dm-spl;
-};
-
-_i2c3_gpio {
- u-boot,dm-spl;
-};
-
-_pmic {
- u-boot,dm-spl;
-};
-
-_uart1 {
- u-boot,dm-spl;
-};
-
-_usdhc2 {
- u-boot,dm-spl;
-};
-
-_usdhc2_100mhz {
- u-boot,dm-spl;
-};
-
-_usdhc2_200mhz {
- u-boot,dm-spl;
-};
-
-_usdhc2_vmmc {
- u-boot,dm-spl;
-};
-
-_usdhc3 {
- u-boot,dm-spl;
-};
-
-_usdhc3_100mhz {
- u-boot,dm-spl;
-};
-
-_usdhc3_100mhz {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-
- regulators {
- u-boot,dm-spl;
- };
-};
-
-_usdhc2_vmmc {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
-/* SDIO WiFi */
- {
- status = "disabled";
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
+#include "imx8mp-dhcom-u-boot.dtsi"
diff --git a/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
new file mode 100644
index 000..ae838caebcf
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+ aliases {
+ eeprom0 =
+ eeprom1 =
+ mmc0 = /* MicroSD */
+ mmc1 = /* eMMC */
+ mmc2 = /* SDIO */
+ };
+
+ config {
+ dh,ram-coding-gpios = < 22 0>, < 23 0>, < 24
0>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_i2c3 {
+ u-boot,dm-spl;
+};
+
+_i2c3_gpio {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_uart1 {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc2_100mhz {
+ u-boot,dm-spl;
+};
+
+_usdhc2_200mhz {
+ u-boot,dm-spl;
+};
+
+_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+ u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+
+ regulators {
+ u-boot,dm-spl;
+ };
+};
+
+_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+/* SDIO WiFi */
+ {
+ status = "disabled";
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
--
2.35.1
[PATCH 4/7] ARM: dts: imx: Add SoM compatible to i.MX8M Plus DHCOM PDK2
Add SoM compatible string into i.MX8MP DHCOM PDK2 compatible strings.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: uboot-imx
---
arch/arm/dts/imx8mp-dhcom-pdk2.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2.dts
b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
index 0fcead35879..c9a481ac9a8 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk2.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
@@ -16,7 +16,8 @@
/ {
model = "DH electronics i.MX8M Plus DHCOM Premium Developer Kit (2)";
- compatible = "dh,imx8mp-dhcom-pdk2", "fsl,imx8mp";
+ compatible = "dh,imx8mp-dhcom-pdk2", "dh,imx8mp-dhcom-som",
+"fsl,imx8mp";
chosen {
stdout-path =
--
2.35.1
[PATCH 2/7] ARM: dts: imx: Add HW variant details to i.MX8M Plus DHCOM PDK2
Add information about which exact SoM variant is used on which PDK2 variant. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: uboot-imx --- arch/arm/dts/imx8mp-dhcom-pdk2.dts | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2.dts b/arch/arm/dts/imx8mp-dhcom-pdk2.dts index e95abfb3e89..7148234a4f1 100644 --- a/arch/arm/dts/imx8mp-dhcom-pdk2.dts +++ b/arch/arm/dts/imx8mp-dhcom-pdk2.dts @@ -1,6 +1,11 @@ // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright (C) 2022 Marek Vasut + * + * DHCOM iMX8MP variant: + * DHCM-iMX8ML8-C160-R409-F1638-SPI16-GE-CAN2-SD-RTC-WBTA-ADC-T-RGB-CSI2-HS-I-01D2 + * DHCOM PCB number: 660-100 or newer + * PDK2 PCB number: 516-400 or newer */ /dts-v1/; -- 2.35.1
[PATCH 1/7] ARM: imx: Enable USB ethernet on i.MX8M Plus DHCOM
Enable both USB CDC ethernet and USB host ethernet on i.MX8M Plus DHCOM. This is useful for bringing up systems without ethernet plug, but with either USB host or gadget plug. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: uboot-imx --- configs/imx8mp_dhcom_pdk2_defconfig | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/configs/imx8mp_dhcom_pdk2_defconfig b/configs/imx8mp_dhcom_pdk2_defconfig index f3b69070698..2ea5c9a2b1b 100644 --- a/configs/imx8mp_dhcom_pdk2_defconfig +++ b/configs/imx8mp_dhcom_pdk2_defconfig @@ -86,6 +86,7 @@ CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_SHA1SUM=y CONFIG_SHA1SUM_VERIFY=y +CONFIG_CMD_BIND=y CONFIG_CMD_CLK=y CONFIG_CMD_DFU=y CONFIG_CMD_FUSE=y @@ -239,20 +240,23 @@ CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y CONFIG_USB=y # CONFIG_SPL_DM_USB is not set +CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_XHCI_DWC3_OF_SIMPLE=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_DWC3=y -# CONFIG_USB_DWC3_GADGET is not set CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_STORAGE=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_ASIX=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="DH electronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 -CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x0 CONFIG_USB_FUNCTION_ACM=y +CONFIG_USB_ETHER=y +CONFIG_USB_ETH_CDC=y CONFIG_IMX_WATCHDOG=y CONFIG_OF_LIBFDT_OVERLAY=y -- 2.35.1
[PATCH v2 3/4] thermal: add sandbox driver
Provide a simple sandbox driver for the thermal uclass.
It simply registers and returns 100 degrees C if requested.
Signed-off-by: Robert Marko
---
arch/sandbox/dts/sandbox.dtsi | 4
arch/sandbox/dts/test.dts | 4
configs/sandbox_defconfig | 2 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/thermal_sandbox.c | 36 +++
5 files changed, 47 insertions(+)
create mode 100644 drivers/thermal/thermal_sandbox.c
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index aa22b8765c..c24aee1d05 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -426,6 +426,10 @@
sandbox_tee {
compatible = "sandbox,tee";
};
+
+ thermal {
+ compatible = "sandbox,thermal";
+ };
};
_ec {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index d1a8cc7bfb..f002233064 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1668,6 +1668,10 @@
compatible = "sandbox,regmap_test";
};
};
+
+ thermal {
+ compatible = "sandbox,thermal";
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb48..d4965248d4 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -77,6 +77,7 @@ CONFIG_CMD_PCI=y
CONFIG_CMD_READ=y
CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_SPI=y
+CONFIG_CMD_TEMPERATURE=y
CONFIG_CMD_USB=y
CONFIG_CMD_AXI=y
CONFIG_CMD_SETEXPR_FMT=y
@@ -282,6 +283,7 @@ CONFIG_SYSINFO=y
CONFIG_SYSINFO_SANDBOX=y
CONFIG_SYSINFO_GPIO=y
CONFIG_SYSRESET=y
+CONFIG_DM_THERMAL=y
CONFIG_TIMER=y
CONFIG_TIMER_EARLY=y
CONFIG_SANDBOX_TIMER=y
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 6dda62bcd1..f2ee1df394 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,6 +4,7 @@
# Author: Nitin Garg
obj-$(CONFIG_DM_THERMAL) += thermal-uclass.o
+obj-$(CONFIG_SANDBOX) += thermal_sandbox.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
obj-$(CONFIG_IMX_SCU_THERMAL) += imx_scu_thermal.o
obj-$(CONFIG_SPARX5_THERMAL) += sparx5-temp.o
diff --git a/drivers/thermal/thermal_sandbox.c
b/drivers/thermal/thermal_sandbox.c
new file mode 100644
index 00..acc364feb0
--- /dev/null
+++ b/drivers/thermal/thermal_sandbox.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 Sartura Ltd.
+ * Written by Robert Marko
+ *
+ * Sandbox driver for the thermal uclass.
+ */
+
+#include
+#include
+#include
+
+int sandbox_thermal_get_temp(struct udevice *dev, int *temp)
+{
+ /* Simply return 100°C */
+ *temp = 100;
+
+ return 0;
+}
+
+static const struct dm_thermal_ops sandbox_thermal_ops = {
+ .get_temp = sandbox_thermal_get_temp,
+};
+
+static const struct udevice_id sandbox_thermal_ids[] = {
+ { .compatible = "sandbox,thermal" },
+ { }
+};
+
+U_BOOT_DRIVER(thermal_sandbox) = {
+ .name = "thermal-sandbox",
+ .id = UCLASS_THERMAL,
+ .of_match = sandbox_thermal_ids,
+ .ops= _thermal_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
2.37.1
[PATCH v2 4/4] test: cmd: add test for temperature command
Add simple test for the temperature command.
Signed-off-by: Robert Marko
---
test/cmd/Makefile | 1 +
test/cmd/temperature.c | 39 +++
2 files changed, 40 insertions(+)
create mode 100644 test/cmd/temperature.c
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index c331757425..f9493357a5 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o
obj-$(CONFIG_CMD_PINMUX) += pinmux.o
obj-$(CONFIG_CMD_PWM) += pwm.o
obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
+obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
diff --git a/test/cmd/temperature.c b/test/cmd/temperature.c
new file mode 100644
index 00..2a1ea0611d
--- /dev/null
+++ b/test/cmd/temperature.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Executes tests for temperature command
+ *
+ * Copyright (C) 2022 Sartura Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int dm_test_cmd_temperature(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+
+ ut_assertok(uclass_get_device(UCLASS_THERMAL, 0, ));
+ ut_assertnonnull(dev);
+
+ ut_assertok(console_record_reset_enable());
+
+ /* Test that "temperature list" shows the sandbox device */
+ ut_assertok(run_command("temperature list", 0));
+ ut_assert_nextline("| Device| Driver
| Parent");
+ ut_assert_nextline("| thermal | thermal-sandbox
| root_driver");
+ ut_assert_console_end();
+
+ /* Test that "temperature get thermal" returns expected value */
+ console_record_reset();
+ ut_assertok(run_command("temperature get thermal", 0));
+ ut_assert_nextline("thermal: 100 C");
+ ut_assert_console_end();
+
+ return 0;
+}
+
+DM_TEST(dm_test_cmd_temperature, UT_TESTF_SCAN_FDT | UT_TESTF_CONSOLE_REC);
--
2.37.1
[PATCH v2 1/4] cmd: add temperature command
Currently, there is no way for users to check the readings from thermal
sensors from U-boot console, only some boards print it during boot.
So, lets add a simple "temperature" command that allows listing thermal
uclass devices and getting their value.
Note that the thermal devices are intenionally probed if list is used as
almost always they will not get probed otherwise and there is no way for
users to manually call probe on a certain device from console.
Assumption is made that temperature is returned in degrees C and not
milidegrees like in Linux as this is what most drivers seem to return.
Signed-off-by: Robert Marko
---
Changes in v2:
* Drop by using uclass_get_device_by_name()
* Make the unit clear in help
* Expand Kconfig boolean and help
* Drop degree symbol as test doesnt work with it.
---
cmd/Kconfig | 6
cmd/Makefile | 1 +
cmd/temperature.c | 85 +++
3 files changed, 92 insertions(+)
create mode 100644 cmd/temperature.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3625ff2a50..ffbfed1f38 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1435,6 +1435,12 @@ config DEFAULT_SPI_MODE
depends on CMD_SPI
default 0
+config CMD_TEMPERATURE
+ bool "temperature - display the temperature from thermal sensors"
+ depends on DM_THERMAL
+ help
+ Provides a way to list thermal sensors and to get their readings.
+
config CMD_TSI148
bool "tsi148 - Command to access tsi148 device"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 5e43a1e022..8874462f1a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_CMD_STRINGS) += strings.o
obj-$(CONFIG_CMD_SMC) += smccc.o
obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o
obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
+obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
obj-$(CONFIG_CMD_TERMINAL) += terminal.o
obj-$(CONFIG_CMD_TIME) += time.o
obj-$(CONFIG_CMD_TIMER) += timer.o
diff --git a/cmd/temperature.c b/cmd/temperature.c
new file mode 100644
index 00..420965de14
--- /dev/null
+++ b/cmd/temperature.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+/*
+ * Copyright (c) 2022 Sartura Ltd.
+ * Written by Robert Marko
+ */
+
+#include
+#include
+#include
+#include
+
+#define LIMIT_DEVNAME 30
+
+static int do_get(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct udevice *dev;
+ int ret, temp;
+
+ if (argc < 2) {
+ printf("thermal device not selected\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = uclass_get_device_by_name(UCLASS_THERMAL, argv[1], );
+ if (ret) {
+ printf("thermal device not found\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = thermal_get_temp(dev, );
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ printf("%s: %d C\n", dev->name, temp);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_list(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct udevice *dev;
+
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Device",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Driver",
+ "Parent");
+
+ uclass_foreach_dev_probe(UCLASS_THERMAL, dev) {
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->name,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->driver->name,
+ dev->parent->name);
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl temperature_subcmd[] = {
+ U_BOOT_CMD_MKENT(list, 1, 1, do_list, "", ""),
+ U_BOOT_CMD_MKENT(get, 2, 1, do_get, "", ""),
+};
+
+static int do_temperature(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct cmd_tbl *cmd;
+
+ argc--;
+ argv++;
+
+ cmd = find_cmd_tbl(argv[0], temperature_subcmd,
ARRAY_SIZE(temperature_subcmd));
+ if (!cmd || argc > cmd->maxargs)
+ return CMD_RET_USAGE;
+
+ return cmd->cmd(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(temperature, CONFIG_SYS_MAXARGS, 1, do_temperature,
+ "thermal sensor temperature",
+ "list\t\tshow list of temperature sensors\n"
+ "get [thermal device name]\tprint temperature in degrees C"
+);
--
2.37.1
[PATCH v2 2/4] doc: cmd: temperature: add documentation
Add documentation for the temperature command. Signed-off-by: Robert Marko --- doc/usage/cmd/temperature.rst | 50 +++ doc/usage/index.rst | 1 + 2 files changed, 51 insertions(+) create mode 100644 doc/usage/cmd/temperature.rst diff --git a/doc/usage/cmd/temperature.rst b/doc/usage/cmd/temperature.rst new file mode 100644 index 00..a5144ec50f --- /dev/null +++ b/doc/usage/cmd/temperature.rst @@ -0,0 +1,50 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +temperature command +=== + +Synopsis + + +:: + +temperature list +temperature get [thermal device name] + +Description +--- + +The *temperature* command is used to list thermal sensors and get their +readings. + +The 'temperature list' command diplays the available thermal devices. + +The 'temperature get' command is used to get the reading in degrees C from +the desired device which is selected by passing its device name. + +thermal device name +device name of thermal sensor to select + +Example +--- + +:: + + +=> temperature list +| Device| Driver| Parent +| tmon@610508110| sparx5-temp | axi@6 +=> +=> temperature get tmon@610508110 +tmon@610508110: 42 C + +Configuration +- + +The *temperature* command is only available if CONFIG_CMD_TEMPERATURE=y. + +Return value + + +The return value $? is set to 0 (true) if the command succeeded and to 1 (false) +otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 2ba8733b92..b6f307b2bd 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -62,6 +62,7 @@ Shell commands cmd/scp03 cmd/setexpr cmd/size + cmd/temperature cmd/true cmd/ums cmd/wdt -- 2.37.1
[PATCH] riscv: dts: Sync important Unmatched pmic and qspi0 changes from Linux
This adds the onkey, RTC and watchdog children to the DA9063 PMIC node,
fixes the compatible for qspi0's flash node to match the official DT
schema (it being an is25wp256 is discoverable, hence jedec,spi-nor is
the only compatible that should be present) and exposes the card detect
GPIO.
Note that the device trees still diverge in some places (including
important things like the PCIe controller's clock name) and should be
cleaned up so that a common device tree is used in both projects rather
than having different bindings. This patch does not attempt to do that,
merely expose important functionality present in Linux's that is not in
U-Boot's so that it can be used without the OS providing its own bundled
copy.
Signed-off-by: Jessica Clarke
---
arch/riscv/dts/hifive-unmatched-a00.dts | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/dts/hifive-unmatched-a00.dts
b/arch/riscv/dts/hifive-unmatched-a00.dts
index b44e8c160d..ea32ae72e8 100644
--- a/arch/riscv/dts/hifive-unmatched-a00.dts
+++ b/arch/riscv/dts/hifive-unmatched-a00.dts
@@ -76,6 +76,18 @@
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ };
+
+ rtc {
+ compatible = "dlg,da9063-rtc";
+ };
+
+ wdt {
+ compatible = "dlg,da9063-watchdog";
+ };
+
regulators {
vdd_bcore1: bcore1 {
regulator-min-microvolt = <105>;
@@ -217,7 +229,7 @@
{
status = "okay";
flash@0 {
- compatible = "issi,is25wp256", "jedec,spi-nor";
+ compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <5000>;
m25p,fast-read;
@@ -234,6 +246,7 @@
spi-max-frequency = <2000>;
voltage-ranges = <3300 3300>;
disable-wp;
+ gpios = < 15 GPIO_ACTIVE_LOW>;
};
};
--
2.31.1
[RFC PATCH v2 9/9] tools: spkgimage: add Renesas SPKG format
Renesas RZ/N1 devices contain BootROM code that loads a custom SPKG
image from QSPI, NAND or USB DFU. Support this format in mkimage tool.
SPKGs can optionally be signed, however creation of signed SPKG is not
currently supported.
Example of how to use it:
tools/mkimage -n board/schneider/lces/spkgimage.cfg \
-T spkgimage -a 0x2004 -e 0x2004 \
-d u-boot.bin u-boot.bin.spkg
The config file (spkgimage.cfg in this example) contains additional
parameters such as NAND ECC settings.
Signed-off-by: Ralph Siemsen
---
Changes in v2:
- rewrote the stand-alone spkg_utility to integrate into mkimage
board/schneider/lces/spkgimage.cfg | 26 +++
boot/image.c | 1 +
include/image.h| 1 +
tools/Makefile | 1 +
tools/spkgimage.c | 303 +
tools/spkgimage.h | 39
6 files changed, 371 insertions(+)
create mode 100644 board/schneider/lces/spkgimage.cfg
create mode 100644 tools/spkgimage.c
create mode 100644 tools/spkgimage.h
diff --git a/board/schneider/lces/spkgimage.cfg
b/board/schneider/lces/spkgimage.cfg
new file mode 100644
index 00..b5faf96b00
--- /dev/null
+++ b/board/schneider/lces/spkgimage.cfg
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2022 Schneider Electric
+#
+# SPKG image header, for booting on RZ/N1
+
+# b[35:32] SPKG version
+VERSION1
+
+# b[42:41] ECC Block size: 0=256 bytes, 1=512 bytes, 2=1024 bytes
+NAND_ECC_BLOCK_SIZE1
+
+# b[45] NAND enable (boolean)
+NAND_ECC_ENABLE1
+
+# b[50:48] ECC Scheme: 0=BCH2 1=BCH4 2=BCH8 3=BCH16 4=BCH24 5=BCH32
+NAND_ECC_SCHEME3
+
+# b[63:56] ECC bytes per block
+NAND_BYTES_PER_ECC_BLOCK 28
+
+# Provide dummy BLp header (boolean)
+ADD_DUMMY_BLP 1
+
+# Pad the image to a multiple of
+PADDING64K
diff --git a/boot/image.c b/boot/image.c
index 5dcb55ba46..7d50d708ab 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -179,6 +179,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_COPRO, "copro", "Coprocessor Image"},
{ IH_TYPE_SUNXI_EGON, "sunxi_egon", "Allwinner eGON Boot Image"
},
{ IH_TYPE_SUNXI_TOC0, "sunxi_toc0", "Allwinner TOC0 Boot Image"
},
+ { IH_TYPE_RENESAS_SPKG, "spkgimage", "Renesas SPKG Image" },
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index e4c6a50b88..98eaa384f4 100644
--- a/include/image.h
+++ b/include/image.h
@@ -229,6 +229,7 @@ enum {
IH_TYPE_COPRO, /* Coprocessor Image for remoteproc*/
IH_TYPE_SUNXI_EGON, /* Allwinner eGON Boot Image */
IH_TYPE_SUNXI_TOC0, /* Allwinner TOC0 Boot Image */
+ IH_TYPE_RENESAS_SPKG, /* Renesas SPKG image */
IH_TYPE_COUNT, /* Number of image types */
};
diff --git a/tools/Makefile b/tools/Makefile
index 005e7362a3..7e24f3ecb9 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -131,6 +131,7 @@ dumpimage-mkimage-objs := aisimage.o \
stm32image.o \
$(ROCKCHIP_OBS) \
socfpgaimage.o \
+ spkgimage.o \
sunxi_egon.o \
lib/crc16-ccitt.o \
lib/hash-checksum.o \
diff --git a/tools/spkgimage.c b/tools/spkgimage.c
new file mode 100644
index 00..2e8c17d94a
--- /dev/null
+++ b/tools/spkgimage.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Generate Renesas RZ/N1 BootROM header (SPKG)
+ * (C) Copyright 2022 Schneider Electric
+ *
+ * Based on spkg_utility.c
+ * (C) Copyright 2016 Renesas Electronics Europe Ltd
+ */
+
+#include "imagetool.h"
+#include
+#include
+#include
+#include
+#include
+#include "spkgimage.h"
+
+static struct spkg_file out_buf;
+
+static uint32_t padding;
+
+/* Note: the ordering of the bitfields does not matter */
+static struct config_file {
+ unsigned int version:1;
+ unsigned int ecc_block_size:2;
+ unsigned int ecc_enable:1;
+ unsigned int ecc_scheme:3;
+ unsigned int ecc_bytes:8;
+ unsigned int blp_len;
+ unsigned int padding;
+} conf;
+
+static int spkgimage_parse_config_line(char *line)
+{
+ char *saveptr;
+ char *delim = "\t ";
+ char *name = strtok_r(line, delim, );
+ char *val_str = strtok_r(NULL, delim, );
+ int value = atoi(val_str);
+
+ if (!strcmp("VERSION", name)) {
+ conf.version = value;
+ } else if (!strcmp("NAND_ECC_ENABLE", name)) {
+ conf.ecc_enable = value;
+ } else if (!strcmp("NAND_ECC_BLOCK_SIZE", name)) {
+ conf.ecc_block_size = value;
+ } else if (!strcmp("NAND_ECC_SCHEME", name)) {
+
Re: [RFC PATCH v1 9/9] tools: Add tool to create Renesas SPKG images
On Tue, Aug 9, 2022 at 1:15 PM Sean Anderson wrote: > > The traditional way to handle this is to specify a config file with -n. > See e.g. mtk_image Thanks Pali and Sean. I have converted this tool to work as part of mkimage, with a config file for the extra parameters. Patch v2 to follow. Ralph
Re: [PATCH v2 00/35] vbe: Verified Boot for Embedded initial support
On Sat, 30 Jul 2022 15:52:02 -0600, Simon Glass wrote: > This adds the concept of a VBE method to U-Boot, along with an > implementation of the 'VBE simple' method, basically a simple way of > updating firmware in MMC from userspace and monitoring it from U-Boot. > > VBE simple is implemented in fwupd. U-Boot's role is to set up the > device tree with the required firmware-update properties and provide the > developer with information about the current VBE state. To that end this > series includes a new 'vbe' command that allows VBE methods to be listed > and examined. > > [...] Applied to u-boot/u-boot.git/master, thanks! -- Tom
Re: binman warning/failure when blobs are missing
On Fri, Aug 12, 2022 at 09:11:11AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 11 Aug 2022 at 19:03, Tom Rini wrote: > > > > On Thu, Aug 11, 2022 at 06:08:51PM -0600, Simon Glass wrote: > > > Hi, > > > > > > On Thu, 11 Aug 2022 at 11:44, Tom Rini wrote: > > > > > > > > On Thu, Aug 11, 2022 at 09:59:05AM -0700, Tim Harvey wrote: > > > > > On Thu, Aug 11, 2022 at 9:48 AM Tom Rini wrote: > > > > > > > > > > > > On Thu, Aug 11, 2022 at 09:27:44AM -0700, Tim Harvey wrote: > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > After a couple of hours troubleshooting a bad boot image today I > > > > > > > realized the issue was that I had some 0 byte files for the lpddr4 > > > > > > > training blobs that are part of the imx8mp binman created image. > > > > > > > > > > > > > > Digging in I found that if a blob referenced in the binman node is > > > > > > > missing a warning will be output but the missing files will be > > > > > > > 'created' as 0 byte files such that the next time you build you > > > > > > > will > > > > > > > get no warning (but will have a non-working image). Additionally > > > > > > > the > > > > > > > error does not cause a non-zero exit code. > > > > > > > > > > > > > > I'm not that fluent in python these days, and don't have the time > > > > > > > for > > > > > > > a while to try and fix this but I figured I would at least send > > > > > > > this > > > > > > > email in case someone else does. > > > > > > > > > > > > > > Example: > > > > > > > # rm *lpddr4*.bin # make sure lpddr4*.bin files referenced in > > > > > > > binman > > > > > > > nodes are missing > > > > > > > # make distclean imx8mp_venice_defconfig flash.bin && echo "build > > > > > > > ok" > > > > > > > ... > > > > > > > BINMAN flash.bin > > > > > > > Image 'main-section' is missing external blobs and is > > > > > > > non-functional: ddr-1d-ime > > > > > > > m-fw ddr-1d-dmem-fw ddr-2d-imem-fw ddr-2d-dmem-fw > > > > > > > Image 'main-section' has faked external blobs and is > > > > > > > non-functional: lpddr4_pmu_ > > > > > > > train_1d_imem_202006.bin lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > > lpddr4_pmu_train_2d > > > > > > > _imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > > > > > > > > > Some images are invalid > > > > > > > ^^^ excellent warning > > > > > > > build ok > > > > > > > ^^^ not so great that there is a successful exit code > > > > > > > # make flash.bin && echo "build ok" > > > > > > > ... > > > > > > > BINMAN flash.bin > > > > > > > build ok > > > > > > > ^^^ absolutely horrible that 0 byte files were created and thus > > > > > > > everything looks good this time around! > > > > > > > # stat -c "%s %n" lpddr4*.bin > > > > > > > 0 lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > > 0 lpddr4_pmu_train_1d_imem_202006.bin > > > > > > > 0 lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > > 0 lpddr4_pmu_train_2d_imem_202006.bin > > > > > > > > > > > > So, this isn't the first time someone has had this problem. On the > > > > > > one > > > > > > hand, we need CI to pass, and not require fetching of arbitrary > > > > > > further > > > > > > images to assemble the binary. On the other hand, we don't want > > > > > > users > > > > > > spending a bunch of time because something didn't work and the > > > > > > normal > > > > > > way of conveying THIS WON'T WORK is a non-zero exit status. Can we > > > > > > easily make some flag for buildman or binman that we do set in CI > > > > > > but > > > > > > won't be set by users? > > > > > > > > > > > > > > > > Tom, > > > > > > > > > > Ok - that makes sense as far as the exit status goes. It would be MUCH > > > > > easier to catch an error like this if binman didn't create 0 byte > > > > > files for missing files so that you at least get the (ascii colored) > > > > > message indicating the image is wrong. > > > > > > Please see this: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220807154708.1418967-2-...@chromium.org/ > > > > > > > > > > > > > I do love the idea of a flag for CI also! > > > > > > > > So, that's part of the root of the problem here. We're passing > > > > --fake-ext-blobs to binman so that it will create those 0 byte files > > > > and it in turn complain. I think we didn't figure out a good way to > > > > tell buildman to pass that to binman tho? > > > > > > I hope the above patch will fix this part of the problem. > > > > I'm not sure. What I really want to see is something like buildman > > --fake-ext-blobs, which in turn does 'make BINMANFLAGS=--fake-ext-blobs' > > or 'make BINMAN_FAKE_EXT_BLOBS=1' and that is what sets --fake-ext-blobs > > to be passed inside of cmd_binman, so that we can tell CI to do that > > (just like we do -E today, to ensure -Werror) but regular users get > > build failures. > > IMO we should add my patch as well as what you are saying here. They > are handling slightly different issues. Yes, the above is useful, to fix a different issue (and should fix some
Re: [PATCH] board: gateworks: venice: poll I2C lines to wait for GSC firmware
On Thu, Aug 11, 2022 at 5:39 PM Peng Fan wrote:
>
>
>
> On 8/12/2022 2:59 AM, Tim Harvey wrote:
> > In some situations the GSC firmware where the EEPROM containing the
> > model and DRAM configuration may not be ready by the time the SoC
> > is ready to talk to it over I2C.
> >
> > Instead of a hard delay, poll the I2C lines to wait until they are
> > released to avoid the I2C drivers 'Arbitation lost' error message.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > arch/arm/dts/imx8mm-venice.dts | 13 +++-
> > arch/arm/dts/imx8mn-venice.dts | 13 +++-
> > arch/arm/dts/imx8mp-venice.dts | 13 +++-
> > board/gateworks/venice/spl.c | 39 ++
> > 4 files changed, 61 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/arm/dts/imx8mm-venice.dts b/arch/arm/dts/imx8mm-venice.dts
> > index 39b030691e53..a1f292fbd9d3 100644
> > --- a/arch/arm/dts/imx8mm-venice.dts
> > +++ b/arch/arm/dts/imx8mm-venice.dts
> > @@ -23,8 +23,11 @@
> >
> >{
> > clock-frequency = <10>;
> > - pinctrl-names = "default";
> > + pinctrl-names = "default", "gpio";
> > pinctrl-0 = <_i2c1>;
> > + pinctrl-1 = <_i2c1_gpio>;
> > + scl-gpios = < 14 GPIO_ACTIVE_HIGH>;
> > + sda-gpios = < 15 GPIO_ACTIVE_HIGH>;
> > status = "okay";
> >
> > gsc: gsc@20 {
> > @@ -89,6 +92,14 @@
> > >;
> > };
> >
> > + pinctrl_i2c1_gpio: i2c1grp-gpio-grp {
> > + fsl,pins = <
> > + MX8MM_IOMUXC_I2C1_SCL_GPIO5_IO140x41c3
> > + MX8MM_IOMUXC_I2C1_SDA_GPIO5_IO150x41c3
> > + >;
> > + u-boot,dm-spl;
> u-boot,dm-spl should be in xx-u-boot.dtsi
>
Peng,
Thanks for catching this! I will fix this and the others in this patch
and send a new version.
Best Regards,
Tim
Re: [PATCH] cmd: add temperature command
On Fri, Aug 12, 2022 at 5:11 PM Simon Glass wrote:
>
> Hi Robert,
>
> On Fri, 12 Aug 2022 at 06:19, Robert Marko wrote:
> >
> > Currently, there is no way for users to check the readings from thermal
> > sensors from U-boot console, only some boards print it during boot.
> >
> > So, lets add a simple "temperature" command that allows listing thermal
> > uclass devices and getting their value.
> >
> > Note that the thermal devices are intenionally probed if list is used as
> > almost always they will not get probed otherwise and there is no way for
> > users to manually call probe on a certain device from console.
> >
> > Assumption is made that temperature is returned in degrees C and not
> > milidegrees like in Linux as this is what most drivers seem to return.
> >
> > Signed-off-by: Robert Marko
> > ---
> > cmd/Kconfig | 6
> > cmd/Makefile | 1 +
> > cmd/temperature.c | 86 +++
> > 3 files changed, 93 insertions(+)
> > create mode 100644 cmd/temperature.c
>
> Don't forget to add doc/usage/command/.. and a sandbox test in test/cmd/
>
> https://u-boot.readthedocs.io/en/latest/develop/testing.html
Yeah, forgot those, will include them in v2.
>
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 3625ff2a50..9bd639c740 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1435,6 +1435,12 @@ config DEFAULT_SPI_MODE
> > depends on CMD_SPI
> > default 0
> >
> > +config CMD_TEMPERATURE
> > + bool "temperature"
>
> How about:
>
> temperature - display the temperature from thermal sensors
>
> > + depends on DM_THERMAL
> > + help
> > + Provides a way to get the temperature reading from thermal
> > sensors.
>
> It also allows listing.
Will expand on this and the previous point.
>
> > +
> > config CMD_TSI148
> > bool "tsi148 - Command to access tsi148 device"
> > help
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 5e43a1e022..8874462f1a 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -152,6 +152,7 @@ obj-$(CONFIG_CMD_STRINGS) += strings.o
> > obj-$(CONFIG_CMD_SMC) += smccc.o
> > obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o
> > obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
> > +obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
> > obj-$(CONFIG_CMD_TERMINAL) += terminal.o
> > obj-$(CONFIG_CMD_TIME) += time.o
> > obj-$(CONFIG_CMD_TIMER) += timer.o
> > diff --git a/cmd/temperature.c b/cmd/temperature.c
> > new file mode 100644
> > index 00..ccf839058e
> > --- /dev/null
> > +++ b/cmd/temperature.c
> > @@ -0,0 +1,86 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +/*
> > + * Copyright (c) 2022 Sartura Ltd.
> > + * Written by Robert Marko
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
>
> I hope you can drop this
>
> > +#include
> > +
> > +#define LIMIT_DEVNAME 30
> > +
> > +static int do_get(struct cmd_tbl *cmdtp, int flag, int argc,
> > + char *const argv[])
> > +{
> > + struct udevice *dev;
> > + int ret, temp;
> > +
> > + if (argc < 2) {
> > + printf("thermal device not selected\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + ret = uclass_get_device_by_name(UCLASS_THERMAL, argv[1], );
>
> You should use the get function normally, since it probes the device
> and for most devices you should only call their methods when the
> device is probed/activated.
I actually wanted the behavior of uclass_get_device_by_name() but completely
missed that it exists, so that is why uclass_foreach_dev_probe() was
used in list
to probe the drivers, but it still allowed for user to directly feed
the device-name
and crash U-boot as device being passed to thermal_get_temp was not probed.
Will switch to uclass_get_device_by_name() in v2 to solve that.
>
> > + if (ret) {
> > + printf("thermal device not found\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + ret = thermal_get_temp(dev, );
> > + if (ret)
> > + return CMD_RET_FAILURE;
> > +
> > + printf("%s: %d°C\n", dev->name, temp);
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > +
> > +static int do_list(struct cmd_tbl *cmdtp, int flag, int argc,
> > + char *const argv[])
> > +{
> > + struct udevice *dev;
> > +
> > + printf("| %-*.*s| %-*.*s| %s\n",
> > + LIMIT_DEVNAME, LIMIT_DEVNAME, "Device",
> > + LIMIT_DEVNAME, LIMIT_DEVNAME, "Driver",
> > + "Parent");
> > +
> > + uclass_foreach_dev_probe(UCLASS_THERMAL, dev) {
> > + printf("| %-*.*s| %-*.*s| %s\n",
> > + LIMIT_DEVNAME, LIMIT_DEVNAME, dev->name,
> > + LIMIT_DEVNAME, LIMIT_DEVNAME, dev->driver->name,
> > + dev->parent->name);
> > + }
>
> BTW as I'm sure you know, this loop probes the device, which is fine.
Re: [PATCH v2 2/6] console: Implement flush() function
On Friday 12 August 2022 09:11:10 Simon Glass wrote:
> Hi Pali,
>
> On Fri, 12 Aug 2022 at 03:01, Pali Rohár wrote:
> >
> > On Thursday 11 August 2022 18:08:46 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Thu, 11 Aug 2022 at 08:50, Pali Rohár wrote:
> > > >
> > > > On Thursday 11 August 2022 08:47:50 Simon Glass wrote:
> > > > > > diff --git a/include/stdio_dev.h b/include/stdio_dev.h
> > > > > > index 270fa2729fb2..06278366ae88 100644
> > > > > > --- a/include/stdio_dev.h
> > > > > > +++ b/include/stdio_dev.h
> > > > > > @@ -37,6 +37,10 @@ struct stdio_dev {
> > > > > > void (*putc)(struct stdio_dev *dev, const char c);
> > > > > > /* To put a string (accelerator) */
> > > > > > void (*puts)(struct stdio_dev *dev, const char *s);
> > > > > > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > > > >
> > > > > I'd argue it isn't worth the #ifdef and we might as well have this
> > > > > member here always. Then you can drop some #ifdefs from your code.
> > > >
> > > > But then it will increase binary code size.
> > >
> > > Using the member will increase code size. But I think the only place
> > > you need an #ifdef for that is when you include it in the driver
> > > struct. You can use __maybe_unused in the other place.
> > >
> > > Having the member will only increase memory usage, not code size.
> >
> > But static memory structures are part of the u-boot.bin binary and also
> > their usage increase code size (required copy, etc...), so at the end it
> > increase code size.
>
> From what I understand stdio_dev is allocated at runtime in BSS:
>
> struct stdio_dev *stdio_devices[] = { NULL, NULL, NULL };
>
> (the NULL stuff should not be there, but does nothing, I believe)
>
> So long as no code accesses your new member, then it should only
> affect the BSS size.
Code of course has to access new member. How otherwise would be able to
call that new callbacks? E.g. all new code in patch 2/6 or 3/6.
> If you are very worried about it, you could use the technique in
> asm-generic/global_data.h to avoid #ifdefs in the C code:
>
> #ifdef CONFIG_GENERATE_ACPI_TABLE
> #define gd_acpi_start() gd->acpi_start
> #define gd_set_acpi_start(addr) gd->acpi_start = addr
> #else
> #define gd_acpi_start() 0UL
> #define gd_set_acpi_start(addr)
> #endif
>
> Regards,
> Simon
Re: [PATCH v2 00/24] blk: Rationalise the block interface
Hi Johan,
On Fri, 12 Aug 2022 at 07:51, Johan Jonker wrote:
>
> Hi Simon and others,
>
> Some comments. Have a look if it's useful.
> Include is an example of how currently a new Rockchip external RKNAND FTL
> block device must be included in U-boot.
> Changes must be made all over the place. EFI has now become a somewhat
> "obligation" for block devices, then handling
> should be made more easy I propose.
>
> 1:
> The creation and removal of block devices is kind of dynamic with the
> blk_create_device function.
> Is it possible to make the necessary functions in efi_device_path.c and
> part.c more flexible as well by
> a new "blk_create_efi_device()" and "blk_remove_efi_device()" function? So
> everything combined in one function.
Do you mean to automatically create a device with the right uclass?
Yes I think that could be done, but I have not looked at it.
>
> 2:
> Make the class list more dynamic/expendable. Each time a new clas is needed
> the source code must be changed.
> Include a function that returns a generated class number that takes in
> account the existing know classes.
> ie,: "uclass_create" and "uclass_remove".
>
> Example block device creation:
>
> ret = uclass_get_device(UCLASS_RK_IDB, 0, );
>
> // Be able to use a dynamic generated UCLASS for block devices.
>
> if (ret) {
> printf("no IDB device found\n");
> return CMD_RET_FAILURE;
> }
> ret = blk_get_device(IF_TYPE_RK_IDB, 0, );
> if (ret) {
> ret = blk_create_device(dev, "idb_blk", "blk",
> IF_TYPE_RK_IDB, 0, 512,
> LBA, );
> if (ret)
> return ret;
>
> ret = blk_probe_or_unbind(bdev);
> if (ret)
> return ret;
> }
>
> Example block device removal:
>
> ret = blk_find_device(IF_TYPE_RK_IDB, 0, );
Note that the IF_TYPE goes away with this series and there is just the uclass.
>
> // Be able to find back a dynamic generated UCLASS.
>
> if (ret) {
> printf("no IDB blk device found\n");
> return 0;
> }
>
> device_remove(bdev, DM_REMOVE_NORMAL);
> device_unbind(bdev);
>
> Make efi functions more flexible by replacing switch() functions by call back
> functions for:
>
> dp_fill
> dp_size
> dev_print
> print_part_header
>
> Add them with "blk_create_efi_device()" in a structure.
> If not defined fall back to standard functions.
We are trying to integrate EFI better into U-Boot so that it uses the
normal devices. At present it has some parallel infrastructure.
Please take a look at your patch after applying this series, then let
me know what you think is needed.
Regards,
Simon
>
>
>
> Kind regards,
>
> Johan Jonker
>
> On 8/12/22 03:34, Simon Glass wrote:
> > The block interface has two separate implementations, one using driver
> > model and one not. The latter is really only needed for SPL, where
> > size constraints allegedly don't allow use of driver model. Of course
> > we still need space for filesystems and other code, so it isn't clear
> > that driver model is anything more than the straw that breaks the
> > camel's back.
> >
> > The driver model version uses a uclass ID for the interface time, but
> > converts back and forth between that and if_type, which is the legacy
> > type.
> >
> > The HAVE_BLOCK_DEVICE define is mostly a hangover from the old days.
> > At present its main purpose is to enable the legacy block implementation
> > in SPL.
> >
> > Finally the use of 'select' to enable BLK does not work very well. It
> > causes kconfig errors when another option depends on BLK and it is
> > not recommended by the kconfig style guide.
> >
> > This series aims to clean things up:
> > - Enable BLK based on whether different media types are used, but still
> > allow boards to disable it
> > - Rename HAVE_BLOCK_DEVICE to indicates its real purpose
> > - Drop if_type and use the uclass instead
> > - Drop some obsolete if_type values
> >
> > An issue not resolved by this series is that the sandbox host interface
> > does not actually have a device. At present it uses the root device, which
> > was convenience for the driver model conversion but not really correct. It
> > should be possible to clean this up, in a future series.
> >
> > Another minor issue is the use of UCLASS_USB for a mass-storage device.
> > This has been the case for a while and is not addresed by this series,
> > other than to add a comment.
> >
> > Note that this test relies on Tom Rini's series to drop various boards
> > including warp and cm_t335
> >
> > Finally, a patch is included to make binman put fake files in a
> > subdirectory, since repeated runs of certain boards can cause unrelated
> > failues (e.g. chromebook_coral) when fake files are left around.
> >
> > Changes in v2:
> > - Update commit
Re: [PATCH] cmd: add temperature command
Hi Robert,
On Fri, 12 Aug 2022 at 06:19, Robert Marko wrote:
>
> Currently, there is no way for users to check the readings from thermal
> sensors from U-boot console, only some boards print it during boot.
>
> So, lets add a simple "temperature" command that allows listing thermal
> uclass devices and getting their value.
>
> Note that the thermal devices are intenionally probed if list is used as
> almost always they will not get probed otherwise and there is no way for
> users to manually call probe on a certain device from console.
>
> Assumption is made that temperature is returned in degrees C and not
> milidegrees like in Linux as this is what most drivers seem to return.
>
> Signed-off-by: Robert Marko
> ---
> cmd/Kconfig | 6
> cmd/Makefile | 1 +
> cmd/temperature.c | 86 +++
> 3 files changed, 93 insertions(+)
> create mode 100644 cmd/temperature.c
Don't forget to add doc/usage/command/.. and a sandbox test in test/cmd/
https://u-boot.readthedocs.io/en/latest/develop/testing.html
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 3625ff2a50..9bd639c740 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1435,6 +1435,12 @@ config DEFAULT_SPI_MODE
> depends on CMD_SPI
> default 0
>
> +config CMD_TEMPERATURE
> + bool "temperature"
How about:
temperature - display the temperature from thermal sensors
> + depends on DM_THERMAL
> + help
> + Provides a way to get the temperature reading from thermal sensors.
It also allows listing.
> +
> config CMD_TSI148
> bool "tsi148 - Command to access tsi148 device"
> help
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 5e43a1e022..8874462f1a 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -152,6 +152,7 @@ obj-$(CONFIG_CMD_STRINGS) += strings.o
> obj-$(CONFIG_CMD_SMC) += smccc.o
> obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o
> obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
> +obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
> obj-$(CONFIG_CMD_TERMINAL) += terminal.o
> obj-$(CONFIG_CMD_TIME) += time.o
> obj-$(CONFIG_CMD_TIMER) += timer.o
> diff --git a/cmd/temperature.c b/cmd/temperature.c
> new file mode 100644
> index 00..ccf839058e
> --- /dev/null
> +++ b/cmd/temperature.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +/*
> + * Copyright (c) 2022 Sartura Ltd.
> + * Written by Robert Marko
> + */
> +
> +#include
> +#include
> +#include
> +#include
I hope you can drop this
> +#include
> +
> +#define LIMIT_DEVNAME 30
> +
> +static int do_get(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct udevice *dev;
> + int ret, temp;
> +
> + if (argc < 2) {
> + printf("thermal device not selected\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + ret = uclass_find_device_by_name(UCLASS_THERMAL, argv[1], );
You should use the get function normally, since it probes the device
and for most devices you should only call their methods when the
device is probed/activated.
> + if (ret) {
> + printf("thermal device not found\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + ret = thermal_get_temp(dev, );
> + if (ret)
> + return CMD_RET_FAILURE;
> +
> + printf("%s: %d°C\n", dev->name, temp);
> +
> + return CMD_RET_SUCCESS;
> +}
> +
> +static int do_list(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct udevice *dev;
> +
> + printf("| %-*.*s| %-*.*s| %s\n",
> + LIMIT_DEVNAME, LIMIT_DEVNAME, "Device",
> + LIMIT_DEVNAME, LIMIT_DEVNAME, "Driver",
> + "Parent");
> +
> + uclass_foreach_dev_probe(UCLASS_THERMAL, dev) {
> + printf("| %-*.*s| %-*.*s| %s\n",
> + LIMIT_DEVNAME, LIMIT_DEVNAME, dev->name,
> + LIMIT_DEVNAME, LIMIT_DEVNAME, dev->driver->name,
> + dev->parent->name);
> + }
BTW as I'm sure you know, this loop probes the device, which is fine.
> +
> + return CMD_RET_SUCCESS;
> +}
> +
> +static struct cmd_tbl temperature_subcmd[] = {
> + U_BOOT_CMD_MKENT(list, 1, 1, do_list, "", ""),
> + U_BOOT_CMD_MKENT(get, 2, 1, do_get, "", ""),
> +};
> +
> +static int do_temperature(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct cmd_tbl *cmd;
> +
> + argc--;
> + argv++;
> +
> + cmd = find_cmd_tbl(argv[0], temperature_subcmd,
> ARRAY_SIZE(temperature_subcmd));
> + if (!cmd || argc > cmd->maxargs)
> + return CMD_RET_USAGE;
> +
> + return cmd->cmd(cmdtp, flag, argc, argv);
> +}
> +
> +U_BOOT_CMD(temperature, CONFIG_SYS_MAXARGS, 1, do_temperature,
> + "thermal sensor temperature",
> + "list\t\tshow
Re: binman warning/failure when blobs are missing
Hi Tom, On Thu, 11 Aug 2022 at 19:03, Tom Rini wrote: > > On Thu, Aug 11, 2022 at 06:08:51PM -0600, Simon Glass wrote: > > Hi, > > > > On Thu, 11 Aug 2022 at 11:44, Tom Rini wrote: > > > > > > On Thu, Aug 11, 2022 at 09:59:05AM -0700, Tim Harvey wrote: > > > > On Thu, Aug 11, 2022 at 9:48 AM Tom Rini wrote: > > > > > > > > > > On Thu, Aug 11, 2022 at 09:27:44AM -0700, Tim Harvey wrote: > > > > > > > > > > > Greetings, > > > > > > > > > > > > After a couple of hours troubleshooting a bad boot image today I > > > > > > realized the issue was that I had some 0 byte files for the lpddr4 > > > > > > training blobs that are part of the imx8mp binman created image. > > > > > > > > > > > > Digging in I found that if a blob referenced in the binman node is > > > > > > missing a warning will be output but the missing files will be > > > > > > 'created' as 0 byte files such that the next time you build you will > > > > > > get no warning (but will have a non-working image). Additionally the > > > > > > error does not cause a non-zero exit code. > > > > > > > > > > > > I'm not that fluent in python these days, and don't have the time > > > > > > for > > > > > > a while to try and fix this but I figured I would at least send this > > > > > > email in case someone else does. > > > > > > > > > > > > Example: > > > > > > # rm *lpddr4*.bin # make sure lpddr4*.bin files referenced in binman > > > > > > nodes are missing > > > > > > # make distclean imx8mp_venice_defconfig flash.bin && echo "build > > > > > > ok" > > > > > > ... > > > > > > BINMAN flash.bin > > > > > > Image 'main-section' is missing external blobs and is > > > > > > non-functional: ddr-1d-ime > > > > > > m-fw ddr-1d-dmem-fw ddr-2d-imem-fw ddr-2d-dmem-fw > > > > > > Image 'main-section' has faked external blobs and is > > > > > > non-functional: lpddr4_pmu_ > > > > > > train_1d_imem_202006.bin lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > lpddr4_pmu_train_2d > > > > > > _imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > > > > > > > Some images are invalid > > > > > > ^^^ excellent warning > > > > > > build ok > > > > > > ^^^ not so great that there is a successful exit code > > > > > > # make flash.bin && echo "build ok" > > > > > > ... > > > > > > BINMAN flash.bin > > > > > > build ok > > > > > > ^^^ absolutely horrible that 0 byte files were created and thus > > > > > > everything looks good this time around! > > > > > > # stat -c "%s %n" lpddr4*.bin > > > > > > 0 lpddr4_pmu_train_1d_dmem_202006.bin > > > > > > 0 lpddr4_pmu_train_1d_imem_202006.bin > > > > > > 0 lpddr4_pmu_train_2d_dmem_202006.bin > > > > > > 0 lpddr4_pmu_train_2d_imem_202006.bin > > > > > > > > > > So, this isn't the first time someone has had this problem. On the one > > > > > hand, we need CI to pass, and not require fetching of arbitrary > > > > > further > > > > > images to assemble the binary. On the other hand, we don't want users > > > > > spending a bunch of time because something didn't work and the normal > > > > > way of conveying THIS WON'T WORK is a non-zero exit status. Can we > > > > > easily make some flag for buildman or binman that we do set in CI but > > > > > won't be set by users? > > > > > > > > > > > > > Tom, > > > > > > > > Ok - that makes sense as far as the exit status goes. It would be MUCH > > > > easier to catch an error like this if binman didn't create 0 byte > > > > files for missing files so that you at least get the (ascii colored) > > > > message indicating the image is wrong. > > > > Please see this: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220807154708.1418967-2-...@chromium.org/ > > > > > > > > > > I do love the idea of a flag for CI also! > > > > > > So, that's part of the root of the problem here. We're passing > > > --fake-ext-blobs to binman so that it will create those 0 byte files > > > and it in turn complain. I think we didn't figure out a good way to > > > tell buildman to pass that to binman tho? > > > > I hope the above patch will fix this part of the problem. > > I'm not sure. What I really want to see is something like buildman > --fake-ext-blobs, which in turn does 'make BINMANFLAGS=--fake-ext-blobs' > or 'make BINMAN_FAKE_EXT_BLOBS=1' and that is what sets --fake-ext-blobs > to be passed inside of cmd_binman, so that we can tell CI to do that > (just like we do -E today, to ensure -Werror) but regular users get > build failures. IMO we should add my patch as well as what you are saying here. They are handling slightly different issues. As to this one, I can make binman return an error result if any images are invalid, controlled with a -W flag, perhaps, as with buildman. It is not just faked blobs - we need to raise a warning/error for missing ones too. Then we could pass -W from CI using an env var picked up by the Makefile as you say. It could control whether --allow-missing and --fake-ext-blobs are passed to binman. Then a normal build will produce errors. We still need
Re: [PATCH v2 2/6] console: Implement flush() function
Hi Pali,
On Fri, 12 Aug 2022 at 03:01, Pali Rohár wrote:
>
> On Thursday 11 August 2022 18:08:46 Simon Glass wrote:
> > Hi Pali,
> >
> > On Thu, 11 Aug 2022 at 08:50, Pali Rohár wrote:
> > >
> > > On Thursday 11 August 2022 08:47:50 Simon Glass wrote:
> > > > > diff --git a/include/stdio_dev.h b/include/stdio_dev.h
> > > > > index 270fa2729fb2..06278366ae88 100644
> > > > > --- a/include/stdio_dev.h
> > > > > +++ b/include/stdio_dev.h
> > > > > @@ -37,6 +37,10 @@ struct stdio_dev {
> > > > > void (*putc)(struct stdio_dev *dev, const char c);
> > > > > /* To put a string (accelerator) */
> > > > > void (*puts)(struct stdio_dev *dev, const char *s);
> > > > > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > > >
> > > > I'd argue it isn't worth the #ifdef and we might as well have this
> > > > member here always. Then you can drop some #ifdefs from your code.
> > >
> > > But then it will increase binary code size.
> >
> > Using the member will increase code size. But I think the only place
> > you need an #ifdef for that is when you include it in the driver
> > struct. You can use __maybe_unused in the other place.
> >
> > Having the member will only increase memory usage, not code size.
>
> But static memory structures are part of the u-boot.bin binary and also
> their usage increase code size (required copy, etc...), so at the end it
> increase code size.
>From what I understand stdio_dev is allocated at runtime in BSS:
struct stdio_dev *stdio_devices[] = { NULL, NULL, NULL };
(the NULL stuff should not be there, but does nothing, I believe)
So long as no code accesses your new member, then it should only
affect the BSS size.
If you are very worried about it, you could use the technique in
asm-generic/global_data.h to avoid #ifdefs in the C code:
#ifdef CONFIG_GENERATE_ACPI_TABLE
#define gd_acpi_start() gd->acpi_start
#define gd_set_acpi_start(addr) gd->acpi_start = addr
#else
#define gd_acpi_start() 0UL
#define gd_set_acpi_start(addr)
#endif
Regards,
Simon
Re: u-boot patch "[v2,02/16] arm: qemu: Add an SPL build" issue help
On Thu, 11 Aug 2022 at 21:02, 曹子恒 wrote: > > Hi, Simon： > it works OK based on your u-boot tree ! > Thank you very much ! OK good, you're welcome! - Simon > > Regards, > ziheng > > From: "Simon Glass" > Date: Thu, Aug 11, 2022, 10:48 PM > Subject: Re: u-boot patch "[v2,02/16] arm: qemu: Add an SPL build" issue help > To: "曹子恒" > Cc: "u-boot@lists.denx.de", > "LV", "李富春", > "王学敏" > Hi ziheng, > > On Thu, 11 Aug 2022 at 00:26, 曹子恒 wrote: > > > > Hi, Simon Glass： > > we have an issue based on this patch below, can you help us ? > > > > Patch：https://patchwork.ozlabs.org/project/uboot/patch/20220117150428.1580273-2-...@chromium.org/ > > > > Our Environment： > > Qemu Version：7.0.0 > > U-boot Baseline Version: 2021.10 > > > > Steps: > > 1. we have only patched "[v2,02/16] arm: qemu: Add an SPL build", > > not all the "passage: Define a standard for firmware data flow" series > > patchs. > > > > 2. Baseed on this patch, we have made the following modifications： > > a. arch/arm/dts/qemu-arm-u-boot.dtsi （Left is original, > > right is modified， we think they are actually the same） > > 3. After compiling, image.bin is generated, image.map is as > > follows（we think it's ok, spl base addr is 0x, and u-boot base addr > > is 0x0001）： > > 4. but when we use following command to execute, it will block. > > command: ./qemu-system-arm -machine virt -nographic -bios image.bin > > result： > > 5. some key files size： > > image.bin： 767936 > > u-boot.bin：694764 > > u-boot-spl.bin：15112 > > > > We don't know what could be causing this problem, hope you can help us ! > > I cannot repeat this problem. > > $ qemu-system-arm -machine virt -nographic -bios > /tmp/b/qemu_arm_spl/image.bin -version > QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.23) > Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers > > I use the tree here: > > https://github.com/sjg20/u-boot/tree/try-qemu > > buildman -k -o /tmp/b/qemu_arm_spl -w qemu_arm_spl > > $ qemu-system-arm -machine virt -nographic -bios /tmp/b/qemu_arm_spl/image.bin > > U-Boot SPL 2022.10-rc2-00042-g5dac8f83d0d-dirty (Aug 11 2022 - 08:36:05 -0600) > Trying to boot from QEMU > > > U-Boot 2022.10-rc2-00042-g5dac8f83d0d-dirty (Aug 11 2022 - 08:36:05 -0600) > > DRAM: 128 MiB > Core: 47 devices, 14 uclasses, devicetree: board > Flash: 32 MiB > Loading Environment from Flash... *** Warning - bad CRC, using default > environment > > In:pl011@900 > Out: pl011@900 > Err: pl011@900 > Net: eth0: virtio-net#32 > Hit any key to stop autoboot: 0 > => QEMU: Terminated > > Regards, > Simon
Re: [PATCH v2 00/24] blk: Rationalise the block interface
Hi Simon and others,
Some comments. Have a look if it's useful.
Include is an example of how currently a new Rockchip external RKNAND FTL block
device must be included in U-boot.
Changes must be made all over the place. EFI has now become a somewhat
"obligation" for block devices, then handling
should be made more easy I propose.
1:
The creation and removal of block devices is kind of dynamic with the
blk_create_device function.
Is it possible to make the necessary functions in efi_device_path.c and part.c
more flexible as well by
a new "blk_create_efi_device()" and "blk_remove_efi_device()" function? So
everything combined in one function.
2:
Make the class list more dynamic/expendable. Each time a new clas is needed the
source code must be changed.
Include a function that returns a generated class number that takes in account
the existing know classes.
ie,: "uclass_create" and "uclass_remove".
Example block device creation:
ret = uclass_get_device(UCLASS_RK_IDB, 0, );
// Be able to use a dynamic generated UCLASS for block devices.
if (ret) {
printf("no IDB device found\n");
return CMD_RET_FAILURE;
}
ret = blk_get_device(IF_TYPE_RK_IDB, 0, );
if (ret) {
ret = blk_create_device(dev, "idb_blk", "blk",
IF_TYPE_RK_IDB, 0, 512,
LBA, );
if (ret)
return ret;
ret = blk_probe_or_unbind(bdev);
if (ret)
return ret;
}
Example block device removal:
ret = blk_find_device(IF_TYPE_RK_IDB, 0, );
// Be able to find back a dynamic generated UCLASS.
if (ret) {
printf("no IDB blk device found\n");
return 0;
}
device_remove(bdev, DM_REMOVE_NORMAL);
device_unbind(bdev);
Make efi functions more flexible by replacing switch() functions by call back
functions for:
dp_fill
dp_size
dev_print
print_part_header
Add them with "blk_create_efi_device()" in a structure.
If not defined fall back to standard functions.
Kind regards,
Johan Jonker
On 8/12/22 03:34, Simon Glass wrote:
> The block interface has two separate implementations, one using driver
> model and one not. The latter is really only needed for SPL, where
> size constraints allegedly don't allow use of driver model. Of course
> we still need space for filesystems and other code, so it isn't clear
> that driver model is anything more than the straw that breaks the
> camel's back.
>
> The driver model version uses a uclass ID for the interface time, but
> converts back and forth between that and if_type, which is the legacy
> type.
>
> The HAVE_BLOCK_DEVICE define is mostly a hangover from the old days.
> At present its main purpose is to enable the legacy block implementation
> in SPL.
>
> Finally the use of 'select' to enable BLK does not work very well. It
> causes kconfig errors when another option depends on BLK and it is
> not recommended by the kconfig style guide.
>
> This series aims to clean things up:
> - Enable BLK based on whether different media types are used, but still
> allow boards to disable it
> - Rename HAVE_BLOCK_DEVICE to indicates its real purpose
> - Drop if_type and use the uclass instead
> - Drop some obsolete if_type values
>
> An issue not resolved by this series is that the sandbox host interface
> does not actually have a device. At present it uses the root device, which
> was convenience for the driver model conversion but not really correct. It
> should be possible to clean this up, in a future series.
>
> Another minor issue is the use of UCLASS_USB for a mass-storage device.
> This has been the case for a while and is not addresed by this series,
> other than to add a comment.
>
> Note that this test relies on Tom Rini's series to drop various boards
> including warp and cm_t335
>
> Finally, a patch is included to make binman put fake files in a
> subdirectory, since repeated runs of certain boards can cause unrelated
> failues (e.g. chromebook_coral) when fake files are left around.
>
> Changes in v2:
> - Update commit message
> - Fix SPL_PARTITIONS too
> - Add SATA also
> - Refer to a suffix, not a prefix
> - Add new patch to handle UCLASS_EFI_MEDIA in dev_print()
> - Add new patch to drop ifname field from struct efi_disk_obj
> - Use conv_uclass_id() instead of the confusing uclass_id_to_uclass_id()
>
>From d0bb794b966a0134a6f321a414b48c28e8894180 Mon Sep 17 00:00:00 2001
From: Johan Jonker
Date: Sun, 7 Aug 2022 15:25:55 +0200
Subject: prepare rknand
diff --git a/disk/part.c b/disk/part.c
index 79955c7fb0..3f8b97a6c6 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -150,6 +150,7 @@ void dev_print (struct blk_desc *dev_desc)
case IF_TYPE_USB:
case IF_TYPE_NVME:
case IF_TYPE_PVBLOCK:
+ case IF_TYPE_RKNAND:
case
Re: [PATCH v3 1/3] Convert CONFIG_SYS_L2_PL310 to Kconfig
On 09.08.22 12:07, Philip Oberfichtner wrote: This converts CONFIG_SYS_L2_PL310 to Kconfig. Signed-off-by: Philip Oberfichtner We used common includes before to select L2_PL31, e.g. for tbs2910 (and many more similar boards) we had mx6_common.h . Now with this conversion lots of individual defconfig files are touched, which creates a very big diffstat. Please use Kconfig defaults for all architectures that used a common include file before, this avoids this defconfig bloat and is much cleaner since the L2 is for sure not board specific. Thanks, Soeren --- Changes in v3: new README| 2 -- arch/arm/Kconfig | 4 arch/arm/mach-mvebu/include/mach/config.h | 2 -- configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_qspiboot_defconfig | 1 + configs/am43xx_evm_rtconly_defconfig | 1 + configs/am43xx_evm_usbhost_boot_defconfig | 1 + configs/am43xx_hs_evm_defconfig | 1 + configs/am43xx_hs_evm_qspi_defconfig | 1 + configs/apalis_imx6_defconfig | 1 + configs/aristainetos2c_defconfig | 1 + configs/aristainetos2ccslb_defconfig | 1 + configs/clearfog_defconfig| 1 + configs/cm_fx6_defconfig | 1 + configs/cm_t43_defconfig | 1 + configs/colibri_imx6_defconfig| 1 + configs/controlcenterdc_defconfig | 1 + configs/crs305-1g-4s-bit_defconfig| 1 + configs/crs305-1g-4s_defconfig| 1 + configs/crs326-24g-2s-bit_defconfig | 1 + configs/crs326-24g-2s_defconfig | 1 + configs/crs328-4c-20s-4s-bit_defconfig| 1 + configs/crs328-4c-20s-4s_defconfig| 1 + configs/db-88f6720_defconfig | 1 + configs/db-88f6820-amc_defconfig | 1 + configs/db-88f6820-gp_defconfig | 1 + configs/db-mv784mp-gp_defconfig | 1 + configs/db-xc3-24g4xg_defconfig | 1 + configs/dh_imx6_defconfig | 1 + configs/display5_defconfig| 1 + configs/display5_factory_defconfig| 1 + configs/ds414_defconfig | 1 + configs/ge_b1x5v2_defconfig | 1 + configs/ge_bx50v3_defconfig | 1 + configs/gwventana_emmc_defconfig | 1 + configs/gwventana_gw5904_defconfig| 1 + configs/gwventana_nand_defconfig | 1 + configs/helios4_defconfig | 1 + configs/imx6dl_icore_nand_defconfig | 1 + configs/imx6dl_mamoj_defconfig| 1 + configs/imx6q_bosch_acc_defconfig | 1 + configs/imx6q_icore_nand_defconfig| 1 + configs/imx6q_logic_defconfig | 1 + configs/imx6qdl_icore_mipi_defconfig | 1 + configs/imx6qdl_icore_mmc_defconfig | 1 + configs/imx6qdl_icore_nand_defconfig | 1 + configs/imx6qdl_icore_rqs_defconfig | 1 + configs/kp_imx6q_tpc_defconfig| 1 + configs/marsboard_defconfig | 1 + configs/maxbcm_defconfig | 1 + configs/mccmon6_nor_defconfig | 1 + configs/mccmon6_sd_defconfig | 1 + configs/mx6cuboxi_defconfig | 1 + configs/mx6memcal_defconfig | 1 + configs/mx6qsabrelite_defconfig | 1 + configs/mx6sabreauto_defconfig| 1 + configs/mx6sabresd_defconfig | 1 + configs/mx6slevk_defconfig| 1 + configs/mx6slevk_spinor_defconfig | 1 + configs/mx6slevk_spl_defconfig| 1 + configs/mx6sllevk_defconfig | 1 + configs/mx6sllevk_plugin_defconfig| 1 + configs/mx6sxsabreauto_defconfig | 1 + configs/mx6sxsabresd_defconfig| 1 + configs/nitrogen6dl2g_defconfig | 1 + configs/nitrogen6dl_defconfig | 1 + configs/nitrogen6q2g_defconfig| 1 + configs/nitrogen6q_defconfig | 1 + configs/nitrogen6s1g_defconfig| 1 + configs/nitrogen6s_defconfig | 1 + configs/novena_defconfig | 1 + configs/omap4_panda_defconfig | 1 + configs/omap4_sdp4430_defconfig | 1 + configs/pcm058_defconfig | 1 + configs/pico-imx6_defconfig | 1 + configs/poleg_evb_defconfig | 1 + configs/riotboard_defconfig | 1 + configs/socfpga_arria10_defconfig | 1 + configs/socfpga_arria5_defconfig | 1 + configs/socfpga_chameleonv3_defconfig | 1 + configs/socfpga_cyclone5_defconfig| 1 + configs/socfpga_dbm_soc1_defconfig| 1 + configs/socfpga_de0_nano_soc_defconfig| 1 + configs/socfpga_de10_nano_defconfig | 1 + configs/socfpga_de10_standard_defconfig | 1 + configs/socfpga_de1_soc_defconfig | 1 + configs/socfpga_is1_defconfig | 1 + configs/socfpga_mcvevk_defconfig
Re: u-boot patch "[v2,02/16] arm: qemu: Add an SPL build" issue help
Hi, Simon： it works OK based on your u-boot tree ! Thank you very much ! Regards, ziheng
Re: [PATCH v1 21/26] imx8mn: synchronise device tree with linux
On Wed, Aug 3, 2022 at 8:02 AM Marcel Ziswiler
wrote:
>
> Hi Adam
>
> On Sun, 2022-07-31 at 11:58 -0500, Adam Ford wrote:
> > On Thu, Jul 21, 2022 at 8:44 AM Marcel Ziswiler wrote:
> > >
> > > From: Marcel Ziswiler
> > >
> > > Synchronise device tree with linux v5.19-rc5.
> > >
> > > Signed-off-by: Marcel Ziswiler
> >
> > For what it's worth to others who may have been impacted, this patch
> > broke my nano booting because the imx8mn.dtsi now has the UART's as
> > subnodes to spba1 which wasn't being included in SPL's device tree.
> > It's likely to impact others who are booting with DM_SERIAL enabled on
> > their Nano.
>
> Sorry about that.
>
> > To fix, I had to add a small line of code to my
> > imx8mn-beacon-kit-u-boot.dtsi file with the following:
> >
> > {
> >u-boot,dm-spl;
> > };
> >
> > With that, my board boots again. If anyone else is using DM_SERIAL
> > and having issues no longer starting, give that a try.
> >
> > Since there are few nano boards with common -u-boot.dtsi entries, it
> > seems like it makes sense to have a common imx8mn-u-boot.dtsi file
> > like we do for Mini and Plus. I'll try to work on that as I have
> > time. (hopefully today)
>
> Thanks for your help in correcting this.
Marcel,
Have you seen the patch series I posted at [1]?
I know Tim Harvey replied 'tested-by' to the cover letter. Might you
have a chance to test it?
[1] - https://patchwork.ozlabs.org/project/uboot/list/?series=312016
>
> Cheers
>
> Marcel
[PATCH] cmd: add temperature command
Currently, there is no way for users to check the readings from thermal
sensors from U-boot console, only some boards print it during boot.
So, lets add a simple "temperature" command that allows listing thermal
uclass devices and getting their value.
Note that the thermal devices are intenionally probed if list is used as
almost always they will not get probed otherwise and there is no way for
users to manually call probe on a certain device from console.
Assumption is made that temperature is returned in degrees C and not
milidegrees like in Linux as this is what most drivers seem to return.
Signed-off-by: Robert Marko
---
cmd/Kconfig | 6
cmd/Makefile | 1 +
cmd/temperature.c | 86 +++
3 files changed, 93 insertions(+)
create mode 100644 cmd/temperature.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3625ff2a50..9bd639c740 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1435,6 +1435,12 @@ config DEFAULT_SPI_MODE
depends on CMD_SPI
default 0
+config CMD_TEMPERATURE
+ bool "temperature"
+ depends on DM_THERMAL
+ help
+ Provides a way to get the temperature reading from thermal sensors.
+
config CMD_TSI148
bool "tsi148 - Command to access tsi148 device"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 5e43a1e022..8874462f1a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_CMD_STRINGS) += strings.o
obj-$(CONFIG_CMD_SMC) += smccc.o
obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o
obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
+obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
obj-$(CONFIG_CMD_TERMINAL) += terminal.o
obj-$(CONFIG_CMD_TIME) += time.o
obj-$(CONFIG_CMD_TIMER) += timer.o
diff --git a/cmd/temperature.c b/cmd/temperature.c
new file mode 100644
index 00..ccf839058e
--- /dev/null
+++ b/cmd/temperature.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+/*
+ * Copyright (c) 2022 Sartura Ltd.
+ * Written by Robert Marko
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define LIMIT_DEVNAME 30
+
+static int do_get(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct udevice *dev;
+ int ret, temp;
+
+ if (argc < 2) {
+ printf("thermal device not selected\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = uclass_find_device_by_name(UCLASS_THERMAL, argv[1], );
+ if (ret) {
+ printf("thermal device not found\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = thermal_get_temp(dev, );
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ printf("%s: %d°C\n", dev->name, temp);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_list(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct udevice *dev;
+
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Device",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Driver",
+ "Parent");
+
+ uclass_foreach_dev_probe(UCLASS_THERMAL, dev) {
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->name,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->driver->name,
+ dev->parent->name);
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl temperature_subcmd[] = {
+ U_BOOT_CMD_MKENT(list, 1, 1, do_list, "", ""),
+ U_BOOT_CMD_MKENT(get, 2, 1, do_get, "", ""),
+};
+
+static int do_temperature(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct cmd_tbl *cmd;
+
+ argc--;
+ argv++;
+
+ cmd = find_cmd_tbl(argv[0], temperature_subcmd,
ARRAY_SIZE(temperature_subcmd));
+ if (!cmd || argc > cmd->maxargs)
+ return CMD_RET_USAGE;
+
+ return cmd->cmd(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(temperature, CONFIG_SYS_MAXARGS, 1, do_temperature,
+ "thermal sensor temperature",
+ "list\t\tshow list of temperature sensors\n"
+ "get [thermal device name]\tprint temperature"
+);
--
2.37.1
Re: [PULL] u-boot-riscv/master
On Thu, Aug 11, 2022 at 09:38:31PM +, Leo Liang wrote: > Hi Tom, > > The following changes since commit cdebee1fd9fa04cc4c972f826bae19b28c253eb0: > > Merge branch '2022-08-10-assorted-updates' (2022-08-10 17:49:20 -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 aa0eda17cf98448c3ef826204f38c76bf48b3345: > > spl: opensbi: convert scratch options to config (2022-08-11 18:46:41 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/13119 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards
On Fri, Aug 12, 2022 at 07:02:17PM +0800, Weijie Gao wrote:
> On Tue, 2022-08-09 at 11:10 +0200, Daniel Golle wrote:
> > Hi Weijie,
> >
> > On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote:
> > > This patch adds general board files based on MT7986 SoCs.
> > >
> > > The SD/eMMC controller on MT7986A and MT7986B have different pin
> > > configurations so that four different reference board configs has
> > > to be
> > > added.
> > >
> > > Signed-off-by: Weijie Gao
> > > ---
> > > [...]
> > > diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h
> > > new file mode 100644
> > > index 00..b28fc0f613
> > > --- /dev/null
> > > +++ b/include/configs/mt7986.h
> > > @@ -0,0 +1,26 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Configuration for MediaTek MT7986 SoC
> > > + *
> > > + * Copyright (C) 2022 MediaTek Inc.
> > > + * Author: Sam Shih
> > > + */
> > > +
> > > +#ifndef __MT7986_H
> > > +#define __MT7986_H
> > > +
> > > +#include
> > > +
> >
> > In the SDK sources I found also
> > #define CONFIG_SYS_BOOTM_LEN SZ_128M
> > here which is actually needed to boot any image with uncompressed
> > kernel larger than 8MiB. As for ARM64 this size is easily exceeded
> > and
> > we got plenty of RAM, I suggest to also include a more generous
> > CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot.
>
> CONFIG_SYS_BOOTM_LEN is now a Kconfig symbol. It will no be defined in
> this header.
> Instead, the default value of this symbol is 0x400 (64M) for ARM64
> which is enough for an ARM64 kernel.
Sorry, I missed c45568cc4e ("Convert CONFIG_SYS_BOOTM_LEN to Kconfig")
and was trying the series on top of U-Boot 2022.07 (for inclusion in
OpenWrt) locally.
I've tested the whole series with Bananapi BPi-R3 (MT7986A) board.
U-Boot itself works great with all 4 boot media options.
The only remaining problem is BootROM header generation using
mkimage/mtk_image for SPI-NOR:
TF-A and U-Boot ithemselves both work well with SPI-NOR when using
'bromutil' to generate the image. When using 'mkimage -T mtk_image'
instead of 'bromutil' the resulting bl2.img doesn't work:
F0: 102B
FA:
V0: 7027 6006 [0001]
00: 1017
FA: 5100
01: 102A 0001
02: 5100
BP: 2000 00C0 [0001]
EC: []
T0: 0213 [010F]
System halt!
Cheers
Daniel
Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards
On Tue, 2022-08-09 at 11:10 +0200, Daniel Golle wrote: > Hi Weijie, > > On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote: > > This patch adds general board files based on MT7986 SoCs. > > > > The SD/eMMC controller on MT7986A and MT7986B have different pin > > configurations so that four different reference board configs has > > to be > > added. > > > > Signed-off-by: Weijie Gao > > --- > > [...] > > diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h > > new file mode 100644 > > index 00..b28fc0f613 > > --- /dev/null > > +++ b/include/configs/mt7986.h > > @@ -0,0 +1,26 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Configuration for MediaTek MT7986 SoC > > + * > > + * Copyright (C) 2022 MediaTek Inc. > > + * Author: Sam Shih > > + */ > > + > > +#ifndef __MT7986_H > > +#define __MT7986_H > > + > > +#include > > + > > In the SDK sources I found also > #define CONFIG_SYS_BOOTM_LEN SZ_128M > here which is actually needed to boot any image with uncompressed > kernel larger than 8MiB. As for ARM64 this size is easily exceeded > and > we got plenty of RAM, I suggest to also include a more generous > CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot. CONFIG_SYS_BOOTM_LEN is now a Kconfig symbol. It will no be defined in this header. Instead, the default value of this symbol is 0x400 (64M) for ARM64 which is enough for an ARM64 kernel. > > > > +#define CONFIG_SYS_NONCACHED_MEMORYSZ_1M > > +#define CONFIG_SYS_MMC_ENV_DEV 0 > > + > > +/* Uboot definition */ > > +#define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE > > + > > +/* SPL -> Uboot */ > > +#define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE > > + > > +/* DRAM */ > > +#define CONFIG_SYS_SDRAM_BASE 0x4000 > > + > > +#endif > > -- > > 2.17.1 > >
Re: [PATCH v2 2/2] rockchip: rk3399: remove duplicate call to regulators_enable_boot_on
Hi all,
Gentle ping on the series.
Cheers,
Quentin
On 7/22/22 12:09, Quentin Schulz wrote:
From: Quentin Schulz
An earlier commit makes the common SPL code call
regulators_enable_boot_on and regulators_enable_boot_off before
iterating over possible boot media for U-Boot proper. There is therefore
no need to do this in the rk3399-specific code, so let's remove it.
Cc: Quentin Schulz
Tested-by: Xavier Drudis Ferran
Signed-off-by: Quentin Schulz
---
This patch depends on:
-
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220722093014.3850165-2D1-2Dfoss-2Buboot-400leil.net_=DwIDAg=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=tN3yjAlaBf8feDQRU2WyKBEH_wplRDDMlbjvLOk5c2B1O74m9e5VmLNibPUvEanQ=_eg_QaLIJjw9hvQOrnFP1GJtrrgxnKP2feaC1mWG4i0=
-
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220722093014.3850165-2D2-2Dfoss-2Buboot-400leil.net_=DwIDAg=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=tN3yjAlaBf8feDQRU2WyKBEH_wplRDDMlbjvLOk5c2B1O74m9e5VmLNibPUvEanQ=Sb2uWDQ7C0ZeT6n0AP5oOGVE0-_dMvOpEh4uUPfGy5U=
v2:
- added Tested-by,
arch/arm/mach-rockchip/rk3399/rk3399.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index fc1acaf4bd..94d0fa58c4 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -280,15 +280,5 @@ void spl_board_init(void)
if (cru->glb_rst_st != 0)
rk3399_force_power_on_reset();
}
-
- if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) {
- /*
-* Turning the eMMC and SPI back on (if disabled via the Qseven
-* BIOS_ENABLE) signal is done through a always-on regulator).
-*/
- if (regulators_enable_boot_on(false))
- debug("%s: Cannot enable boot on regulator\n",
- __func__);
- }
}
#endif
Re: [PATCH v3 1/2] rockchip: rk3399: fix incorrect ifdef check on SPL_DM_REGULATOR
Hi all,
Gentle ping on the series.
Cheers,
Quentin
On 7/22/22 11:30, Quentin Schulz wrote:
From: Quentin Schulz
The check to perform is on CONFIG_SPL_DM_REGULATOR and not
SPL_DM_REGULATOR. Also switch to in-code check instead of ifdefs.
Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
v2:
- use IS_ENABLED checks,
arch/arm/mach-rockchip/rk3399/rk3399.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 01a05599cd..8205511c25 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -275,13 +275,14 @@ void spl_board_init(void)
rk3399_force_power_on_reset();
#endif
-#if defined(SPL_DM_REGULATOR)
- /*
-* Turning the eMMC and SPI back on (if disabled via the Qseven
-* BIOS_ENABLE) signal is done through a always-on regulator).
-*/
- if (regulators_enable_boot_on(false))
- debug("%s: Cannot enable boot on regulator\n", __func__);
-#endif
+ if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) {
+ /*
+* Turning the eMMC and SPI back on (if disabled via the Qseven
+* BIOS_ENABLE) signal is done through a always-on regulator).
+*/
+ if (regulators_enable_boot_on(false))
+ debug("%s: Cannot enable boot on regulator\n",
+ __func__);
+ }
}
#endif
Re: [PATCH 2/2] rockchip: rk3399: sync spl_boot_devices_tbl and boot_devices node paths
Hi all,
Gentle ping on the series.
Cheers,
Quentin
On 7/18/22 23:12, Xavier Drudis Ferran wrote:
El Fri, Jul 15, 2022 at 05:15:52PM +0200, Quentin Schulz deia:
From: Quentin Schulz
While technically not a bug, let's have some consistency in paths
returned by u-boot,spl-boot-order look-up and the one saved in
u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices
node paths.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
Tested on a Rock-Pi-4B and didn't see any regression.
Tested-by: Xavier Drudis Ferran
Reviewed-by: Xavier Drudis Ferran
arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index f280cb1dbf..7147dc09f5 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device)
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC2, "/mmc@fe32" },
{ BOOT_DEVICE_MMC1, "/mmc@fe33" },
- { BOOT_DEVICE_SPI, "/spi@ff1d" },
+ { BOOT_DEVICE_SPI, "/spi@ff1d/flash@0" },
};
for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)
--
2.36.1
Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name
Hi all,
Gentle ping.
Cheers,
Quentin
On 7/29/22 02:32, Art Nikpal wrote:
On Mon, Jul 18, 2022 at 5:19 PM Quentin Schulz
wrote:
On 7/11/22 20:22, Xavier Drudis Ferran wrote:
El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:
From: Quentin Schulz
When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.
This is due to an incorrect look-up in the Device Tree. Since commit
822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe33 to mmc@fe33
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.
Yes, I also saw that. I changed and tested it at some time, but since there
were other changes, I hesitate to send a Tested by for your patch. FWIW:
Reviewed-by: Xavier Drudis Ferran
Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
Sorry for resend, was not yet subscribed.
arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 01a05599cd..de11a3fa30 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define GRF_BASE 0xff77
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-[BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
+[BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
};
@@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
const char *ofpath;
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
-{ BOOT_DEVICE_MMC2, "/sdhci@fe33" },
+{ BOOT_DEVICE_MMC2, "/mmc@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },
Not related to this patch, but I also changed "/spi@ff1d" ->
"/spi@ff1d/flash@0".
Not sure whether it needs to be different in both arrays in some case for some
reason.
please apply this
Tested-by: Lapkin Artem
Thanks for the heads up, it seems that our board was the only (upstream)
one impacted by this oversight because it's the only one reading
u-boot,spl-boot-device DT property that is set using this table.
See patch here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220715151552.953654-2D2-2Dfoss-2Buboot-400leil.net_=DwIBaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=TsF8K1B_cl2VOPRkkGPtRpzBQKwwn-bDUpvuJK5HdOqfnZC1LdVxMACHi1R6b3NT=9cXes6CWGj1g_BMo_Ph2Hm6nlBm6iIswzF64hEuvnBg=
You can add your Suggested-by: I forgot to add it before sending.
please apply this too, i have send same patch for right spi flash node
name before
Suggested-by: Lapkin Artem
Tested-by: Lapkin Artem
Thanks!
Quentin
Re: [PATCH 17/31] i2c: add support for MediaTek I2C interface
On Wed, 2022-08-10 at 13:24 +0200, Michael Nazzareno Trimarchi wrote: > Hi > > On Thu, Aug 4, 2022 at 5:38 AM Weijie Gao > wrote: > > > > This patch adds support for MediaTek I2C interface > > > > Signed-off-by: Weijie Gao > > --- > > drivers/i2c/Kconfig | 9 + > > drivers/i2c/Makefile | 1 + > > drivers/i2c/mtk_i2c.c | 822 > > ++ > > 3 files changed, 832 insertions(+) > > create mode 100644 drivers/i2c/mtk_i2c.c > > > > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig > > index be4724bf8e..08b6c7bdcc 100644 > > --- a/drivers/i2c/Kconfig > > +++ b/drivers/i2c/Kconfig > > @@ -261,6 +261,15 @@ config SYS_I2C_MESON > > internal buffer holding up to 8 bytes for transfers and > > supports > > both 7-bit and 10-bit addresses. > > > > +config SYS_I2C_MTK > > + bool "MediaTek I2C driver" > > + help > > + This selects the MediaTek Integrated Inter Circuit bus > > driver. > > + The I2C bus adapter is the base for some other I2C > > client, > > + eg: touch, sensors. > > + If you want to use MediaTek I2C interface, say Y here. > > + If unsure, say N. > > + > > config SYS_I2C_MICROCHIP > > bool "Microchip I2C driver" > > help > > diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile > > index 7e046f809a..920aafb91c 100644 > > --- a/drivers/i2c/Makefile > > +++ b/drivers/i2c/Makefile > > @@ -32,6 +32,7 @@ obj-$(CONFIG_SYS_I2C_MICROCHIP) += i2c- > > microchip.o > > obj-$(CONFIG_SYS_I2C_MV) += mv_i2c.o > > obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o > > obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o > > +obj-$(CONFIG_SYS_I2C_MTK) += mtk_i2c.o > > obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o > > obj-$(CONFIG_SYS_I2C_NPCM) += npcm_i2c.o > > obj-$(CONFIG_SYS_I2C_OCORES) += ocores_i2c.o > > diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c > > new file mode 100644 > > index 00..1d4a93f8c9 > > --- /dev/null > > +++ b/drivers/i2c/mtk_i2c.c > > @@ -0,0 +1,822 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright (C) 2022 MediaTek Inc. All Rights Reserved. > > + * > > + * Author: Mingming Lee > > + * > > + * MediaTek I2C Interface driver > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define I2C_RS_TRANSFERBIT(4) > > +#define I2C_HS_NACKERR BIT(2) > > +#define I2C_ACKERR BIT(1) > > +#define I2C_TRANSAC_COMP BIT(0) > > +#define I2C_TRANSAC_START BIT(0) > > +#define I2C_RS_MUL_CNFGBIT(15) > > +#define I2C_RS_MUL_TRIGBIT(14) > > +#define I2C_DCM_DISABLE0x > > +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003 > > +#define I2C_IO_CONFIG_PUSH_PULL0x > > +#define I2C_SOFT_RST 0x0001 > > +#define I2C_FIFO_ADDR_CLR 0x0001 > > +#define I2C_DELAY_LEN 0x0002 > > +#define I2C_ST_START_CON 0x8001 > > +#define I2C_FS_START_CON 0x1800 > > +#define I2C_TIME_CLR_VALUE 0x > > +#define I2C_TIME_DEFAULT_VALUE 0x0003 > > +#define I2C_WRRD_TRANAC_VALUE 0x0002 > > +#define I2C_RD_TRANAC_VALUE0x0001 > > + > > +#define I2C_DMA_CON_TX 0x > > +#define I2C_DMA_CON_RX 0x0001 > > +#define I2C_DMA_START_EN 0x0001 > > +#define I2C_DMA_INT_FLAG_NONE 0x > > +#define I2C_DMA_CLR_FLAG 0x > > +#define I2C_DMA_TX_RX 0x > > +#define I2C_DMA_HARD_RST 0x0002 > > + > > +#define MAX_ST_MODE_SPEED 10 > > +#define MAX_FS_MODE_SPEED 40 > > +#define MAX_HS_MODE_SPEED 340 > > +#define MAX_SAMPLE_CNT_DIV 8 > > +#define MAX_STEP_CNT_DIV 64 > > +#define MAX_HS_STEP_CNT_DIV8 > > +#define I2C_DEFAULT_CLK_DIV4 > > + > > +#define MAX_I2C_ADDR 0x7f > > +#define MAX_I2C_LEN0xff > > +#define TRANS_ADDR_ONLYBIT(8) > > +#define TRANSFER_TIMEOUT 5 /* us */ > > +#define I2C_FIFO_STAT1_MASK0x001f > > +#define TIMING_SAMPLE_OFFSET 8 > > +#define HS_SAMPLE_OFFSET 12 > > +#define HS_STEP_OFFSET 8 > > + > > +#define I2C_CONTROL_WRAPPERBIT(0) > > +#define I2C_CONTROL_RS BIT(1) > > +#define I2C_CONTROL_DMA_EN BIT(2) > > +#define I2C_CONTROL_CLK_EXT_EN BIT(3) > > +#define I2C_CONTROL_DIR_CHANGE BIT(4) > > +#define I2C_CONTROL_ACKERR_DET_EN BIT(5) > > +#define I2C_CONTROL_TRANSFER_LEN_CHANGE BIT(6) > > +#define I2C_CONTROL_DMAACK BIT(8) > > +#define I2C_CONTROL_ASYNC BIT(9) > > + > >
RE: [PATCH 1/1] Migration: set deadline for move to DM_GPIO
> Subject: Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO > > On Wed, Aug 03, 2022 at 07:27:50PM +0200, Heinrich Schuchardt wrote: > > On 8/3/22 18:26, Quentin Schulz wrote: > > > Hi Tom, > > > > > > On 8/3/22 18:08, Tom Rini wrote: > > > > On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > Only five boards are left that need to be migrated to DM_GPIO. > > > > > Set a > > > > > 2023.04 deadline. > > > > > > > > > > * edminiv2_defconfig > > > > > * mx28evk_auart_console_defconfig > > > > > * mx28evk_nand_defconfig > > > > > * mx28evk_spi_defconfig > > > > > * warp_defconfig > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > > > > > > > > I see you've now ack'd Fabio's patch to remove those mx28 configs. > > > > Here's my patch to remove edminiv2: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.29 > > > > 88464-6-tr...@konsulko.com/ > > > > > > > > That leaves just "warp", which is missing a ton of conversions, so > > > > let me just post a removal patch instead and see where it goes. > > > > > > > > > > I guess this would also mean the removal of GPIO drivers that > > > haven't moved to DM? > > > > > > # git grep -L UCLASS drivers/gpio/*.c drivers/gpio/adi_gpio2.c > > > drivers/gpio/kona_gpio.c drivers/gpio/kw_gpio.c > > > drivers/gpio/mpc83xx_gpio.c drivers/gpio/mvgpio.c > > > drivers/gpio/pca953x.c drivers/gpio/pca9698.c drivers/gpio/sh_pfc.c > > > drivers/gpio/tca642x.c > > > > I tried to remove the drivers but that leads to errors in > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13021 > > I did a similar test, but on top of my DM_ETH branch so some platforms got > removed already. The fatal platform list is: > SBx81LIFKW lschlv2 lsxhl dns325 km_kirkwood km_kirkwood_128m16 > km_kirkwood_pci kmcoge5un kmnusa kmsuse2 d2net_v2 net2big_v2 > inetspace_v2 netspace_lite_v2 netspace_max_v2 netspace_mini_v2 > netspace_v2 omap5_uevm > > and I've cc'd the maintainers. Folks, are you able to pick up and convert the > GPIO driver that your platform relies on to DM_GPIO soon, or should we just > disable the GPIO driver? Or drop the platform? Thanks! > the platforms km_kirkwood km_kirkwood_128m16 km_kirkwood_pci kmcoge5un kmnusa kmsuse2 we can drop. I will prepare a patch at the beginning of the next week to remove them. Best regards Holger
Re: [PATCH v2 2/6] console: Implement flush() function
On Thursday 11 August 2022 18:08:46 Simon Glass wrote:
> Hi Pali,
>
> On Thu, 11 Aug 2022 at 08:50, Pali Rohár wrote:
> >
> > On Thursday 11 August 2022 08:47:50 Simon Glass wrote:
> > > > diff --git a/include/stdio_dev.h b/include/stdio_dev.h
> > > > index 270fa2729fb2..06278366ae88 100644
> > > > --- a/include/stdio_dev.h
> > > > +++ b/include/stdio_dev.h
> > > > @@ -37,6 +37,10 @@ struct stdio_dev {
> > > > void (*putc)(struct stdio_dev *dev, const char c);
> > > > /* To put a string (accelerator) */
> > > > void (*puts)(struct stdio_dev *dev, const char *s);
> > > > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > >
> > > I'd argue it isn't worth the #ifdef and we might as well have this
> > > member here always. Then you can drop some #ifdefs from your code.
> >
> > But then it will increase binary code size.
>
> Using the member will increase code size. But I think the only place
> you need an #ifdef for that is when you include it in the driver
> struct. You can use __maybe_unused in the other place.
>
> Having the member will only increase memory usage, not code size.
But static memory structures are part of the u-boot.bin binary and also
their usage increase code size (required copy, etc...), so at the end it
increase code size.
> Regards,
> Simon
Re: [PATCH v2 5/6] serial: Call flush() before changing baudrate
On Thursday 11 August 2022 18:08:45 Simon Glass wrote:
> Hi Pali,
>
> On Thu, 11 Aug 2022 at 08:51, Pali Rohár wrote:
> >
> > On Thursday 11 August 2022 08:47:53 Simon Glass wrote:
> > > On Thu, 11 Aug 2022 at 06:39, Pali Rohár wrote:
> > > >
> > > > Changing baudrate is sensitive operation. To ensure that U-Boot messages
> > >
> > > is a sensitive
> > >
> > > > printed before changing baudrate are not lost, call new U-Boot console
> > > > flush() function.
> > > >
> > > > Signed-off-by: Pali Rohár
> > > > ---
> > > > cmd/load.c | 5 +
> > > > drivers/serial/serial-uclass.c | 1 +
> > > > drivers/serial/serial.c| 1 +
> > > > 3 files changed, 7 insertions(+)
> > > >
> > > > diff --git a/cmd/load.c b/cmd/load.c
> > > > index e44ae0d56b75..5c4f34781d45 100644
> > > > --- a/cmd/load.c
> > > > +++ b/cmd/load.c
> > > > @@ -83,6 +83,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp, int
> > > > flag, int argc,
> > > > printf("## Switch baudrate to %d bps and press ENTER
> > > > ...\n",
> > > > load_baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > gd->baudrate = load_baudrate;
> > > > serial_setbrg();
> > > > udelay(5);
> > > > @@ -126,6 +127,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp,
> > > > int flag, int argc,
> > > > printf("## Switch baudrate to %d bps and press ESC
> > > > ...\n",
> > > > current_baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > gd->baudrate = current_baudrate;
> > > > serial_setbrg();
> > > > udelay(5);
> > > > @@ -317,6 +319,7 @@ int do_save_serial(struct cmd_tbl *cmdtp, int flag,
> > > > int argc,
> > > > printf("## Switch baudrate to %d bps and press ESC
> > > > ...\n",
> > > > (int)current_baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > gd->baudrate = current_baudrate;
> > > > serial_setbrg();
> > > > udelay(5);
> > > > @@ -471,6 +474,7 @@ static int do_load_serial_bin(struct cmd_tbl
> > > > *cmdtp, int flag, int argc,
> > > > printf("## Switch baudrate to %d bps and press ENTER
> > > > ...\n",
> > > > load_baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > gd->baudrate = load_baudrate;
> > > > serial_setbrg();
> > > > udelay(5);
> > > > @@ -533,6 +537,7 @@ static int do_load_serial_bin(struct cmd_tbl
> > > > *cmdtp, int flag, int argc,
> > > > printf("## Switch baudrate to %d bps and press ESC
> > > > ...\n",
> > > > current_baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > gd->baudrate = current_baudrate;
> > > > serial_setbrg();
> > > > udelay(5);
> > > > diff --git a/drivers/serial/serial-uclass.c
> > > > b/drivers/serial/serial-uclass.c
> > > > index 4e32270d4660..0f6860d9100e 100644
> > > > --- a/drivers/serial/serial-uclass.c
> > > > +++ b/drivers/serial/serial-uclass.c
> > > > @@ -527,6 +527,7 @@ static int on_baudrate(const char *name, const char
> > > > *value, enum env_op op,
> > > > printf("## Switch baudrate to %d bps and press
> > > > ENTER ...\n",
> > > >baudrate);
> > > > udelay(5);
> > > > + flush();
> > > > }
> > > >
> > > > gd->baudrate = baudrate;
> > > > diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> > > > index 6cdbb89841c1..4b525b644928 100644
> > > > --- a/drivers/serial/serial.c
> > > > +++ b/drivers/serial/serial.c
> > > > @@ -81,6 +81,7 @@ static int on_baudrate(const char *name, const char
> > > > *value, enum env_op op,
> > > > printf("## Switch baudrate to %d"
> > > > " bps and press ENTER ...\n", baudrate);
> > > > udelay(5);
> > > > + flush();
> > >
> > > Please don't implement new features in legacy code.
> >
> > Sorry, I do not know what is the legacy code in this spaghetti monster.
>
> This file is legacy...you only need to change the uclass.
Ok
> >
> > > > }
> > > >
> > > > gd->baudrate = baudrate;
> > > > --
> > > > 2.20.1
> > > >
> > >
> > > Regards,
> > > SImon
>
> Regards,
> Simon
[PATCH v2] bootstage: Show func name for bootstage_mark/error
bootstage_mark() and bootstate_error() are not recording any name and in
report it is showing as id=. That's not useful and it is better to
show function name which calls it.
That's why use macros with passing __func__ as recorded name for bootstage.
Origin report looks like this:
ZynqMP> bootstage report
Timer summary in microseconds (10 records):
MarkElapsed Stage
0 0 reset
2,482,383 2,482,383 board_init_f
4,278,821 1,796,438 board_init_r
4,825,331546,510 id=64
4,858,409 33,078 id=65
4,862,382 3,973 main_loop
4,921,713 59,331 usb_start
9,345,345 4,423,632 id=175
When this patch is applied.
ZynqMP> bootstage report
Timer summary in microseconds (31 records):
MarkElapsed Stage
0 0 reset
2,465,624 2,465,624 board_init_f
4,278,628 1,813,004 board_init_r
4,825,139546,511 eth_common_init
4,858,228 33,089 eth_initialize
4,862,201 3,973 main_loop
4,921,530 59,329 usb_start
8,885,334 3,963,804 cli_loop
Signed-off-by: Michal Simek
---
Changes in v2:
- Add kernel-doc description
common/bootstage.c | 10 ++
include/bootstage.h | 21 ++---
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/common/bootstage.c b/common/bootstage.c
index 0fd33be97eae..326c40f1561f 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -147,15 +147,9 @@ ulong bootstage_add_record(enum bootstage_id id, const
char *name,
return mark;
}
-
-ulong bootstage_mark(enum bootstage_id id)
-{
- return bootstage_add_record(id, NULL, 0, timer_get_boot_us());
-}
-
-ulong bootstage_error(enum bootstage_id id)
+ulong bootstage_error_name(enum bootstage_id id, const char *name)
{
- return bootstage_add_record(id, NULL, BOOTSTAGEF_ERROR,
+ return bootstage_add_record(id, name, BOOTSTAGEF_ERROR,
timer_get_boot_us());
}
diff --git a/include/bootstage.h b/include/bootstage.h
index bca9438418f5..7088d0b875e4 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -268,12 +268,27 @@ ulong bootstage_add_record(enum bootstage_id id, const
char *name,
/**
* Mark a time stamp for the current boot stage.
*/
-ulong bootstage_mark(enum bootstage_id id);
-
-ulong bootstage_error(enum bootstage_id id);
+#define bootstage_mark(id) bootstage_mark_name(id, __func__)
+#define bootstage_error(id)bootstage_error_name(id, __func__)
+/**
+ * bootstage_mark_name - record bootstage with passing id and name
+ * @id: Bootstage id to record this timestamp against
+ * @name: Textual name to display for this id in the report
+ *
+ * Return: recorded time stamp
+ */
ulong bootstage_mark_name(enum bootstage_id id, const char *name);
+/**
+ * bootstage_error_name - record bootstage error with passing id and name
+ * @id: Bootstage id to record this timestamp against
+ * @name: Textual name to display for this id in the report
+ *
+ * Return: recorded time stamp
+ */
+ulong bootstage_error_name(enum bootstage_id id, const char *name);
+
/**
* Mark a time stamp in the given function and line number
*
--
2.36.1
Re: [PATCH] bootstage: Show func name for bootstage_mark/error
On 8/11/22 16:47, Simon Glass wrote:
Hi Michal,
On Thu, 11 Aug 2022 at 06:46, Michal Simek wrote:
bootstage_mark() and bootstate_error() are not recording any name and in
report it is showing as id=. That's not useful and it is better to
show function name which calls it.
That's why use macros with passing __func__ as recorded name for bootstage.
Origin report looks like this:
ZynqMP> bootstage report
Timer summary in microseconds (10 records):
MarkElapsed Stage
0 0 reset
2,482,383 2,482,383 board_init_f
4,278,821 1,796,438 board_init_r
4,825,331546,510 id=64
4,858,409 33,078 id=65
4,862,382 3,973 main_loop
4,921,713 59,331 usb_start
9,345,345 4,423,632 id=175
When this patch is applied.
ZynqMP> bootstage report
Timer summary in microseconds (31 records):
MarkElapsed Stage
0 0 reset
2,465,624 2,465,624 board_init_f
4,278,628 1,813,004 board_init_r
4,825,139546,511 eth_common_init
4,858,228 33,089 eth_initialize
4,862,201 3,973 main_loop
4,921,530 59,329 usb_start
8,885,334 3,963,804 cli_loop
Signed-off-by: Michal Simek
---
common/bootstage.c | 10 ++
include/bootstage.h | 5 +++--
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/common/bootstage.c b/common/bootstage.c
index 0fd33be97eae..326c40f1561f 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -147,15 +147,9 @@ ulong bootstage_add_record(enum bootstage_id id, const
char *name,
return mark;
}
-
-ulong bootstage_mark(enum bootstage_id id)
-{
- return bootstage_add_record(id, NULL, 0, timer_get_boot_us());
-}
-
-ulong bootstage_error(enum bootstage_id id)
+ulong bootstage_error_name(enum bootstage_id id, const char *name)
{
- return bootstage_add_record(id, NULL, BOOTSTAGEF_ERROR,
+ return bootstage_add_record(id, name, BOOTSTAGEF_ERROR,
timer_get_boot_us());
}
diff --git a/include/bootstage.h b/include/bootstage.h
index bca9438418f5..8d9ef7362f8b 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -268,9 +268,10 @@ ulong bootstage_add_record(enum bootstage_id id, const
char *name,
/**
* Mark a time stamp for the current boot stage.
*/
-ulong bootstage_mark(enum bootstage_id id);
+#define bootstage_mark(id) bootstage_mark_name(id, __func__)
+#define bootstage_error(id)bootstage_error_name(id, __func__)
-ulong bootstage_error(enum bootstage_id id);
+ulong bootstage_error_name(enum bootstage_id id, const char *name);
Please can you add proper comments to these functions?
Will add kernel-doc in v2.
ulong bootstage_mark_name(enum bootstage_id id, const char *name);
Also I think you need to add code for when BOOTSTAGE is not enabled,
later in the header.
They are already there.
Thanks,
Michal
Re: [RESEND PATCH] arm: kirkwood: nsa310s: Add Distro boot capability
Hi Stefan,
On Thu, Aug 11, 2022 at 10:29 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 12.08.22 01:40, Tony Dinh wrote:
> > - Add distro boot to board include file and deconfig file
> > - Miscellaneous changes:
> > - Remove Gerald from maintainer list (email bounced)
> > - Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
> > kernel method of booting (e.g. OpenWrt) with appended DTB.
> > - Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
> >
> > Note that this patch is depended on the following patch:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
> >
> > Signed-off-by: Tony Dinh
>
> So did you change anything here? Last time you mentioned, that you need
> to resend this patch. I assumed that you needed to make some changes.
Sorry, I was not clear about the reason for RESEND. I inadvertently
removed the existing envs for booting with the UBIFS partition. In
this patch, I only implemented distro boot for USB and SATA, so I
should keep UBI booting the same way as before. In this RESED patch
I've restored those envs.
#define CONFIG_EXTRA_ENV_SETTINGS \
"console=console=ttyS0,115200\0" \
"kernel=/boot/zImage\0" \
"fdt=/boot/nsa310s.dtb\0" \
- "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0"
+ "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0" \
+ LOAD_ADDRESS_ENV_SETTINGS \
+ BOOTENV
+
Thanks,
Tony
>
> Thanks,
> Stefan
>
> > ---
> >
> > board/zyxel/nsa310s/MAINTAINERS | 1 -
> > configs/nsa310s_defconfig | 17 +
> > include/configs/nsa310s.h | 31 +--
> > 3 files changed, 34 insertions(+), 15 deletions(-)
> >
> > diff --git a/board/zyxel/nsa310s/MAINTAINERS
> > b/board/zyxel/nsa310s/MAINTAINERS
> > index d153758c21..11106acf3e 100644
> > --- a/board/zyxel/nsa310s/MAINTAINERS
> > +++ b/board/zyxel/nsa310s/MAINTAINERS
> > @@ -1,5 +1,4 @@
> > NSA310S BOARD
> > -M: Gerald Kerma
> > M: Tony Dinh
> > M: Luka Perkov
> > S: Maintained
> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
> > index 2b39ae74b3..a5f01ef88e 100644
> > --- a/configs/nsa310s_defconfig
> > +++ b/configs/nsa310s_defconfig
> > @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
> > CONFIG_ARCH_CPU_INIT=y
> > CONFIG_SYS_THUMB_BUILD=y
> > CONFIG_ARCH_KIRKWOOD=y
> > +CONFIG_SUPPORT_PASSING_ATAGS=y
> > +CONFIG_CMDLINE_TAG=y
> > +CONFIG_INITRD_TAG=y
> > CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
> > CONFIG_SYS_TEXT_BASE=0x60
> > CONFIG_SYS_MALLOC_F_LEN=0x400
> > @@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
> > CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
> > CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
> > CONFIG_SYS_LOAD_ADDR=0x80
> > +CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
> > CONFIG_BOOTDELAY=3
> > -CONFIG_USE_BOOTCOMMAND=y
> > -CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts}
> > ${bootargs_root}; ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80
> > ${kernel}; ubifsload 0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt
> > resize; fdt chosen; bootz 0x80 - 0x70"
> > CONFIG_USE_PREBOOT=y
> > # CONFIG_DISPLAY_BOARDINFO is not set
> > -CONFIG_HUSH_PARSER=y
> > CONFIG_SYS_PROMPT="NSA310s> "
> > CONFIG_SYS_MAXARGS=32
> > CONFIG_SYS_PBSIZE=1050
> > -CONFIG_CMD_BOOTZ=y
> > # CONFIG_CMD_FLASH is not set
> > CONFIG_CMD_NAND=y
> > CONFIG_CMD_SATA=y
> > CONFIG_CMD_USB=y
> > # CONFIG_CMD_SETEXPR is not set
> > -CONFIG_CMD_DHCP=y
> > -CONFIG_CMD_MII=y
> > -CONFIG_CMD_PING=y
> > -CONFIG_CMD_EXT2=y
> > -CONFIG_CMD_FAT=y
> > -CONFIG_CMD_FS_GENERIC=y
> > CONFIG_CMD_JFFS2=y
> > CONFIG_CMD_MTDPARTS=y
> > CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
> >
> > CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
> > CONFIG_CMD_UBI=y
> > -CONFIG_ISO_PARTITION=y
> > CONFIG_OF_CONTROL=y
> > CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_IS_IN_NAND=y
> > @@ -65,6 +58,6 @@ CONFIG_MII=y
> > CONFIG_SYS_NS16550=y
> > CONFIG_USB=y
> > CONFIG_USB_EHCI_HCD=y
> > -CONFIG_USB_STORAGE=y
> > +CONFIG_UBIFS_SILENCE_MSG=y
> > CONFIG_LZMA=y
> > CONFIG_BZIP2=y
> > diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
> > index 027a47b5a3..62f0701180 100644
> > --- a/include/configs/nsa310s.h
> > +++ b/include/configs/nsa310s.h
> > @@ -9,15 +9,42 @@
> > #ifndef _CONFIG_NSA310S_H
> > #define _CONFIG_NSA310S_H
> >
> > +/*
> > + * mv-common.h should be defined after CMD configs since it used them
> > + * to enable certain macros
> > + */
> > #include "mv-common.h"
> >
> > -/* default environment variables */
> > +/* Include the common distro boot environment */
> > +#ifndef CONFIG_SPL_BUILD
> > +
> > +#define
Re: [PATCH v3 3/4] arm_ffa: introduce Arm FF-A low-level driver
Hi Abdellatif,
On Mon, 1 Aug 2022 at 20:21, Abdellatif El Khlifi
wrote:
>
> Add the driver implementing Arm Firmware Framework for Armv8-A v1.0
>
> The Firmware Framework for Arm A-profile processors (FF-A)
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
>
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
>
> 32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP
> and FFA_MSG_SEND_DIRECT_{REQ, RESP}.
>
> In u-boot FF-A design, FF-A is considered as a discoverable bus.
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
>
> The driver exports its operations to be used by upper layers.
>
> Exported operations:
>
> - partition_info_get
> - sync_send_receive
> - rxtx_unmap
>
> This implementation provides an optional feature to copy the driver data
> to EFI runtime area.
>
[...]
> +config ARM_FFA_TRANSPORT
> + bool "Enable Arm Firmware Framework for Armv8-A driver"
> + depends on DM && ARM64
> + select ARM_SMCCC
> + select LIB_UUID
> + select DEVRES
> + help
> + The Firmware Framework for Arm A-profile processors (FF-A)
> + describes interfaces (ABIs) that standardize communication
> + between the Secure World and Normal World leveraging TrustZone
> + technology.
> +
> + This driver is based on FF-A specification v1.0 and uses SMC32
> + calling convention.
> +
> + FF-A specification:
> +
> + https://developer.arm.com/documentation/den0077/a/?lang=en
> +
> + In u-boot FF-A design, FF-A is considered as a discoverable bus.
> + The Secure World is considered as one entity to communicate with
> + using the FF-A bus.
> + FF-A communication is handled by one device and one instance (the
> bus).
> + This FF-A driver takes care of all the interactions between Normal
> world
> + and Secure World.
> +
> +config ARM_FFA_EFI_RUNTIME_MODE
> + bool "Enable EFI runtime support for FF-A data and code "
> + depends on ARM_FFA_TRANSPORT && EFI_LOADER
> + help
> + Allows FF-A driver data structures and code to be accessible at EFI
> runtime
Is there a reason we want to opt-in on that? What prevents it from
always being there?
[...]
> +
> +/* Endpoint ID mask (u-boot endpoint ID) */
> +
> +#define GET_SELF_ENDPOINT_ID_MASK GENMASK(15, 0)
> +#define GET_SELF_ENDPOINT_ID(x)\
> + ((u16)(FIELD_GET(GET_SELF_ENDPOINT_ID_MASK, (x
> +
> +#define PREP_SELF_ENDPOINT_ID_MASK GENMASK(31, 16)
> +#define PREP_SELF_ENDPOINT_ID(x) \
> + (FIELD_PREP(PREP_SELF_ENDPOINT_ID_MASK, (x)))
> +
> +/* Partition endpoint ID mask (partition with which u-boot communicates
> with) */
> +
> +#define PREP_PART_ENDPOINT_ID_MASK GENMASK(15, 0)
> +#define PREP_PART_ENDPOINT_ID(x) \
> + (FIELD_PREP(PREP_PART_ENDPOINT_ID_MASK, (x)))
> +
> +/*
> + * Definitions of the Arm FF-A interfaces supported by the Arm FF-A driver
> + */
> +
> +#define FFA_SMC(calling_convention, func_num) \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, (calling_convention), \
> + ARM_SMCCC_OWNER_STANDARD, (func_num))
> +
> +#define FFA_SMC_32(func_num)
> FFA_SMC(ARM_SMCCC_SMC_32, (func_num))
> +#define FFA_SMC_64(func_num)
> FFA_SMC(ARM_SMCCC_SMC_64, (func_num))
> +
> +#define FFA_VERSIONFFA_SMC_32(0x63)
> +#define FFA_ID_GET FFA_SMC_32(0x69)
> +#define FFA_FEATURES FFA_SMC_32(0x64)
> +#define FFA_PARTITION_INFO_GET FFA_SMC_32(0x68)
> +#define FFA_RXTX_UNMAP FFA_SMC_32(0x67)
> +#define FFA_RX_RELEASE FFA_SMC_32(0x65)
> +#define FFA_RUNFFA_SMC_32(0x6D)
> +#define FFA_ERROR FFA_SMC_32(0x60)
> +#define FFA_SUCCESSFFA_SMC_32(0x61)
> +#define FFA_INTERRUPT FFA_SMC_32(0x62)
> +#define FFA_RXTX_MAP FFA_SMC_64(0x66)
> +#define FFA_MSG_SEND_DIRECT_REQFFA_SMC_64(0x6F)
> +#define FFA_MSG_SEND_DIRECT_RESP FFA_SMC_64(0x70)
> +
> +/* The FF-A SMC function definitions */
> +
> +typedef struct arm_smccc_1_2_regs ffa_value_t;
> +typedef void (*invoke_ffa_fn_t)(ffa_value_t args, ffa_value_t
