Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
Please note that this is not a resubmission of fdt_add_pubkey, I merely mentioned that in passing (and cc'ed Roman because of his interest in that) as a previous attempt at solving the problem of getting the public key info baked into U-Boot's .dtb, an approach that I've since learnt is not without problems of its own. So please review this patch on its own merits. Rasmus
Re: FIT image: load secure FPGA
On 05/10/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 04/10/21, Alex G. wrote:
> > On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > Hello,
> > >
>
> hi Alex,
>
> > > We are enabling secure boot on Zynqmp with SPL.
> > >
> > > The issue however is that during secure boot, the bootrom not only
> > > validates the first loader (SPL and PMUFW combo) but it will also
> > > expect a signed bitstream during load(FPGA).
> > >
> > > Since currently the SPL load of an FPGA image from FIT does not
> > > support loading images for authentication (fpga_loads), I'd like to
> > > discuss how to best implement such support.
> >
> > What do you mean by "loading images for authentication" ?
>
> right, it eventually means executing fpga_loads insted of fpga_load (
> a function that will provide additional params to the PMUFW.
>
> "loads" will load FPGA bitstreams that are either signed, encrypted or
> both. When they are only signed, they are first authenticated by the
> PMUFW and then loaded.
>
> > >
> > > A pretty standard file.its description of the FPGA loadable looks like
> > > this:
> > >
> > > fpga {
> > >description = "FPGA binary";
> > >data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
> > >type = "fpga";
> > >arch = "${UBOOT_ARCH}";
> > >compression = "none";
> > >load = <${fpgaloadaddr}>;
> > >hash-1 {
> > >algo = "${FIT_HASH_ALG}";
> > >};
> > >};
> > >
> > > We could extend imagetool.h struct image_tool_params to add more
> > > params or perhpas just define different 'types' of fpga?
> >
> >
> > Check "4) '/images' node"
> > in doc/uImage.FIT/source_file_format.txt
> >
> > The intent is to give either:
> >* loadaddr="$(addr)" : copy image to $(addr), Done
> >* compatible="": Use this driver to upload the FPGA
> >
> > It seems to me like the right way to go is to make a new compatible="" FPGA
> > loader is for fpga_load():
> >
> > fpga {
> > description = "FPGA binary";
> > data = /incbin/("${YOCTO_BS_PATH}");
> > type = "fpga";
> > compression = "none";
> > compatible = "zynqmp-fancy-fpga",
>
> so you think we should capture on compatible the characteristics of the FPGA
> image?
um, right, makes sense then, thanks.
- compatible : compatible method for loading image.
Mandatory for types: "fpga", and images that do not specify a load address.
To use the generic fpga loading routine, use "u-boot,fpga-legacy"
>
> > hash-1 {
> > algo = "${FIT_HASHISH}";
> > };
> > };
> >
> >
> > > Something like:
> > >"fpga"
> > >"fpga-auth" : authenticated
> > >"fpga-enc" : encrypted
> > >"fpga-sec" : encrypted and authenticated
> >
> > Can these properties be inferred from the FPGA image? If not, they could be
> > required when using a new fpga loader. I don't think they should be added to
> > "fpga-legacy".
>
> maybe.. with a bit of boot header parsing... But doing so would
> deviate from the current approach making it somewhat inconsistent: ie,
> there is no a common "fpga load" command but instead we have "fpga
> load" and "fpga loads" as separate commands so perhaps the parsing is
> not that obvious or it would have been done differently.
> I'd rather follow the current approach and just explicitly qualify the
> bitstream.
>
>
>
> >
> > Alex
> >
> > > Then it would be a matter of modifying
> > > https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
> > >
> > > any thoughts?
> > >
> > > TIA
> > > Jorge
> > >
Re: FIT image: load secure FPGA
On 04/10/21, Alex G. wrote:
> On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > Hello,
> >
hi Alex,
> > We are enabling secure boot on Zynqmp with SPL.
> >
> > The issue however is that during secure boot, the bootrom not only
> > validates the first loader (SPL and PMUFW combo) but it will also
> > expect a signed bitstream during load(FPGA).
> >
> > Since currently the SPL load of an FPGA image from FIT does not
> > support loading images for authentication (fpga_loads), I'd like to
> > discuss how to best implement such support.
>
> What do you mean by "loading images for authentication" ?
right, it eventually means executing fpga_loads insted of fpga_load (
a function that will provide additional params to the PMUFW.
"loads" will load FPGA bitstreams that are either signed, encrypted or
both. When they are only signed, they are first authenticated by the
PMUFW and then loaded.
> >
> > A pretty standard file.its description of the FPGA loadable looks like
> > this:
> >
> > fpga {
> >description = "FPGA binary";
> >data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
> >type = "fpga";
> >arch = "${UBOOT_ARCH}";
> >compression = "none";
> >load = <${fpgaloadaddr}>;
> >hash-1 {
> > algo = "${FIT_HASH_ALG}";
> > };
> >};
> >
> > We could extend imagetool.h struct image_tool_params to add more
> > params or perhpas just define different 'types' of fpga?
>
>
> Check "4) '/images' node"
> in doc/uImage.FIT/source_file_format.txt
>
> The intent is to give either:
>* loadaddr="$(addr)" : copy image to $(addr), Done
>* compatible="": Use this driver to upload the FPGA
>
> It seems to me like the right way to go is to make a new compatible="" FPGA
> loader is for fpga_load():
>
> fpga {
> description = "FPGA binary";
> data = /incbin/("${YOCTO_BS_PATH}");
> type = "fpga";
> compression = "none";
> compatible = "zynqmp-fancy-fpga",
so you think we should capture on compatible the characteristics of the FPGA
image?
> hash-1 {
> algo = "${FIT_HASHISH}";
> };
> };
>
>
> > Something like:
> >"fpga"
> >"fpga-auth" : authenticated
> >"fpga-enc" : encrypted
> >"fpga-sec" : encrypted and authenticated
>
> Can these properties be inferred from the FPGA image? If not, they could be
> required when using a new fpga loader. I don't think they should be added to
> "fpga-legacy".
maybe.. with a bit of boot header parsing... But doing so would
deviate from the current approach making it somewhat inconsistent: ie,
there is no a common "fpga load" command but instead we have "fpga
load" and "fpga loads" as separate commands so perhaps the parsing is
not that obvious or it would have been done differently.
I'd rather follow the current approach and just explicitly qualify the
bitstream.
>
> Alex
>
> > Then it would be a matter of modifying
> > https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
> >
> > any thoughts?
> >
> > TIA
> > Jorge
> >
[PATCH v3 16/16] update CAAM MAINTAINER
Signed-off-by: Gaurav Jain --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 40a0e7ac72..e2f601d7cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1258,3 +1258,10 @@ T: git https://source.denx.de/u-boot/u-boot.git F: configs/tools-only_defconfig F: * F: */ + +CAAM +M: Gaurav Jain +S: Maintained +F: drivers/crypto/fsl/ +F: include/fsl_sec.h +F: cmd/blob.c -- 2.17.1
[PATCH v3 15/16] PPC: Enable Job ring driver model in U-Boot
removed sec_init() call and CONFIG_FSL_CAAM from defconfig. sec is initialized based on job ring information processed from device tree. Signed-off-by: Gaurav Jain Reviewed-by: Priyanka Jain --- arch/powerpc/cpu/mpc85xx/Kconfig | 44 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 17 +-- arch/powerpc/include/asm/u-boot-ppc.h | 13 arch/powerpc/include/asm/u-boot.h | 1 + configs/P2041RDB_defconfig| 1 - configs/P3041DS_defconfig | 1 - configs/P4080DS_defconfig | 1 - configs/P5040DS_defconfig | 1 - configs/T1024RDB_defconfig| 1 - configs/T1042D4RDB_defconfig | 1 - configs/T2080QDS_defconfig| 1 - configs/T2080RDB_defconfig| 1 - configs/T4240RDB_defconfig| 1 - 13 files changed, 73 insertions(+), 11 deletions(-) create mode 100644 arch/powerpc/include/asm/u-boot-ppc.h diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 66ebaf529f..4acfc4f95f 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -25,6 +25,10 @@ config TARGET_P3041DS select PHYS_64BIT select ARCH_P3041 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -33,6 +37,10 @@ config TARGET_P4080DS select PHYS_64BIT select ARCH_P4080 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -41,6 +49,10 @@ config TARGET_P5040DS select PHYS_64BIT select ARCH_P5040 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -101,6 +113,10 @@ config TARGET_P2041RDB select ARCH_P2041 select BOARD_LATE_INIT if CHAIN_OF_TRUST select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply FSL_SATA @@ -116,6 +132,10 @@ config TARGET_T1024RDB select SUPPORT_SPL select PHYS_64BIT select FSL_DDR_INTERACTIVE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_EEPROM imply PANIC_HANG @@ -125,6 +145,10 @@ config TARGET_T1042RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT config TARGET_T1042D4RDB bool "Support T1042D4RDB" @@ -132,6 +156,10 @@ config TARGET_T1042D4RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply PANIC_HANG config TARGET_T1042RDB_PI @@ -140,6 +168,10 @@ config TARGET_T1042RDB_PI select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply PANIC_HANG config TARGET_T2080QDS @@ -150,6 +182,10 @@ config TARGET_T2080QDS select PHYS_64BIT select FSL_DDR_FIRST_SLOT_QUAD_CAPABLE select FSL_DDR_INTERACTIVE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA config TARGET_T2080RDB @@ -158,6 +194,10 @@ config TARGET_T2080RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -167,6 +207,10 @@ config TARGET_T4240RDB select SUPPORT_SPL select PHYS_64BIT select FSL_DDR_FIRST_SLOT_QUAD_CAPABLE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index e920e01b25..728c6447a8 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -56,6 +56,7 @@ #ifdef CONFIG_U_QE #include #endif +#include #ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK /* @@ -974,8 +975,6 @@ int cpu_init_r(void) #endif #ifdef CONFIG_FSL_CAAM - sec_init(); - #if defined(CONFIG_ARCH_C29X) if ((SVR_SOC_VER(svr) == SVR_C292) || (SVR_SOC_VER(svr) == SVR_C293)) @@ -1014,6 +1013,20 @@ int cpu_init_r(void) return 0; } +#ifdef CONFI
[PATCH v3 14/16] PPC: Add crypto node in device tree
device tree imported from linux kernel.
c500bee1c5b2 (tag: v5.14-rc4) Linux 5.14-rc4
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/powerpc/dts/p2041si-post.dtsi | 1 +
arch/powerpc/dts/p3041si-post.dtsi | 1 +
arch/powerpc/dts/p4080si-post.dtsi | 1 +
arch/powerpc/dts/p5040si-post.dtsi | 1 +
arch/powerpc/dts/qoriq-sec4.0-0.dtsi | 74 ++
arch/powerpc/dts/qoriq-sec4.2-0.dtsi | 83 +
arch/powerpc/dts/qoriq-sec5.2-0.dtsi | 92
arch/powerpc/dts/t1023si-post.dtsi | 1 +
arch/powerpc/dts/t1042si-post.dtsi | 1 +
arch/powerpc/dts/t2080si-post.dtsi | 1 +
arch/powerpc/dts/t4240si-post.dtsi | 1 +
11 files changed, 257 insertions(+)
create mode 100644 arch/powerpc/dts/qoriq-sec4.0-0.dtsi
create mode 100644 arch/powerpc/dts/qoriq-sec4.2-0.dtsi
create mode 100644 arch/powerpc/dts/qoriq-sec5.2-0.dtsi
diff --git a/arch/powerpc/dts/p2041si-post.dtsi
b/arch/powerpc/dts/p2041si-post.dtsi
index 01ab395950..8819199646 100644
--- a/arch/powerpc/dts/p2041si-post.dtsi
+++ b/arch/powerpc/dts/p2041si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p3041si-post.dtsi
b/arch/powerpc/dts/p3041si-post.dtsi
index 21f322f06f..a3e8088d25 100644
--- a/arch/powerpc/dts/p3041si-post.dtsi
+++ b/arch/powerpc/dts/p3041si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p4080si-post.dtsi
b/arch/powerpc/dts/p4080si-post.dtsi
index 7c3f2fb92e..56b79b14f4 100644
--- a/arch/powerpc/dts/p4080si-post.dtsi
+++ b/arch/powerpc/dts/p4080si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.0-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p5040si-post.dtsi
b/arch/powerpc/dts/p5040si-post.dtsi
index 1efad2d017..fae3ed31a5 100644
--- a/arch/powerpc/dts/p5040si-post.dtsi
+++ b/arch/powerpc/dts/p5040si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec5.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
b/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
new file mode 100644
index 00..ff348d70f1
--- /dev/null
+++ b/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-3-Clause)
+/*
+ * QorIQ Sec/Crypto 4.0 device tree stub [ controller @ offset 0x30 ]
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ */
+
+crypto: crypto@30 {
+ compatible = "fsl,sec-v4.0";
+ fsl,sec-era = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x30 0x1>;
+ ranges = <0 0x30 0x1>;
+ interrupts = <92 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <88 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <89 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <90 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <91 2 0 0>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x80>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x80>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20 0x300 0x80>;
+ };
+
+ rtic_d: rtic-d@60 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x60 0x20 0x500 0x80>;
+ };
+ };
+};
+
+sec_mon: sec_mon@314000 {
+ compatible = "fsl,sec-v4.0-mon";
+ reg = <0x314000 0x1000>;
+ interrupts = <93 2 0 0>;
+};
diff --git a/arch/powerpc/dts/qoriq-sec4.2-0.dtsi
b/arch/powerpc/dts/qoriq-sec
[PATCH v3 13/16] Layerscape: Enable Job ring driver model in U-Boot.
LS(1021/1012/1028/1043/1046/1088/2088), LX2160, LX2162
platforms are enabled with JR driver model.
removed sec_init() call from board files.
removed CONFIG_FSL_CAAM from defconfig files.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/arm/cpu/armv7/ls102xa/Kconfig| 4 +++
arch/arm/cpu/armv7/ls102xa/cpu.c | 16 +++
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 +++
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 10 ++-
board/freescale/ls1012afrdm/ls1012afrdm.c | 7 +
board/freescale/ls1012aqds/ls1012aqds.c | 6 +
board/freescale/ls1012ardb/ls1012ardb.c | 6 +
board/freescale/ls1021aiot/ls1021aiot.c | 6 ++---
board/freescale/ls1021aqds/ls1021aqds.c | 6 +
board/freescale/ls1021atsn/ls1021atsn.c | 7 ++---
board/freescale/ls1021atwr/ls1021atwr.c | 8 ++
board/freescale/ls1028a/ls1028a.c | 6 +
board/freescale/ls1043ardb/ls1043ardb.c | 6 +
board/freescale/ls1046afrwy/ls1046afrwy.c | 7 +
board/freescale/ls1046aqds/ls1046aqds.c | 7 +
board/freescale/ls1046ardb/ls1046ardb.c | 6 +
board/freescale/ls1088a/ls1088a.c | 6 +
board/freescale/ls2080aqds/ls2080aqds.c | 6 +
board/freescale/ls2080ardb/ls2080ardb.c | 9 +--
board/freescale/lx2160a/lx2160a.c | 5
configs/ls1021aiot_qspi_defconfig | 1 -
configs/ls1021aqds_nor_defconfig | 1 -
configs/ls1021aqds_qspi_defconfig | 1 -
configs/ls1021atsn_qspi_defconfig | 1 -
configs/ls1021atwr_nor_defconfig | 1 -
...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 +
configs/ls1028ardb_tfa_defconfig | 1 -
configs/ls1043ardb_tfa_defconfig | 1 -
configs/ls1046afrwy_tfa_defconfig | 1 -
configs/ls1046aqds_tfa_defconfig | 1 -
configs/ls1046ardb_tfa_defconfig | 1 -
configs/ls2088aqds_tfa_defconfig | 1 -
configs/ls2088ardb_tfa_defconfig | 1 -
configs/lx2160aqds_tfa_defconfig | 1 -
configs/lx2160ardb_tfa_defconfig | 1 -
configs/lx2162aqds_tfa_defconfig | 1 -
36 files changed, 75 insertions(+), 102 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 747059b56a..f23c33cbc3 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -20,6 +20,10 @@ config ARCH_LS1021A
select SYS_FSL_SEC_LE
select SYS_FSL_SRDS_1
select SYS_HAS_SERDES
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply CMD_PCI
imply SCSI
imply SCSI_AHCI
diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c b/arch/arm/cpu/armv7/ls102xa/cpu.c
index d863c9625a..4904592703 100644
--- a/arch/arm/cpu/armv7/ls102xa/cpu.c
+++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -20,6 +21,7 @@
#include
#include
#include
+#include
#include "fsl_epu.h"
@@ -397,3 +399,17 @@ void arch_preboot_os(void)
ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl));
}
+
+#ifdef CONFIG_ARCH_MISC_INIT
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 9cef363fba..3fad7eb5a4 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -18,6 +18,10 @@ config ARCH_LS1012A
select SYS_I2C_MXC
select SYS_I2C_MXC_I2C1 if !DM_I2C
select SYS_I2C_MXC_I2C2 if !DM_I2C
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply PANIC_HANG
config ARCH_LS1028A
@@ -50,6 +54,9 @@ config ARCH_LS1028A
select SYS_FSL_ERRATUM_A011334
select SYS_FSL_ESDHC_UNRELIABLE_PULSE_DETECTION_WORKAROUND
select RESV_RAM if GIC_V3_ITS
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
imply PANIC_HANG
config ARCH_LS1043A
@@ -83,6 +90,10 @@ config ARCH_LS1043A
select SYS_I2C_MXC_I2C2 if !DM_I2C
select SYS_I2C_MXC_I2C3 if !DM_I2C
select SYS_I2C_MXC_I2C4 if !DM_I2C
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply CMD_PCI
config ARCH_LS1046A
@@ -117,6 +128,10 @@ config ARCH_LS1046
[PATCH v3 12/16] Layerscape: Add crypto node in device tree
LS(1021/1012/1028/1043/1046/1088/2088), LX2160 - updated device tree
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/arm/dts/fsl-ls1012a.dtsi | 46 ++-
arch/arm/dts/fsl-ls1028a.dtsi | 41 ++-
arch/arm/dts/fsl-ls1043a.dtsi | 45 +-
arch/arm/dts/fsl-ls1046a.dtsi | 44 +
arch/arm/dts/fsl-ls1088a.dtsi | 39 +
arch/arm/dts/fsl-ls2080a.dtsi | 39 +
arch/arm/dts/fsl-lx2160a.dtsi | 41 ++-
arch/arm/dts/ls1021a.dtsi | 40 ++
8 files changed, 331 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 2894842cf2..20ef111d27 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
- * Copyright 2020 NXP
+ * Copyright 2020-2021 NXP
* Copyright 2016 Freescale Semiconductor
*/
@@ -71,6 +71,50 @@
bus-width = <4>;
};
+ crypto: crypto@170 {
+ compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
+"fsl,sec-v4.0";
+ fsl,sec-era = <8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x170 0x10>;
+ reg = <0x00 0x170 0x0 0x10>;
+ interrupts = <0 75 0x4>;
+ dma-coherent;
+
+ sec_jr0: jr@1 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x1 0x1>;
+ interrupts = <0 71 0x4>;
+ };
+
+ sec_jr1: jr@2 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x2 0x1>;
+ interrupts = <0 72 0x4>;
+ };
+
+ sec_jr2: jr@3 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x3 0x1>;
+ interrupts = <0 73 0x4>;
+ };
+
+ sec_jr3: jr@4 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x4 0x1>;
+ interrupts = <0 74 0x4>;
+ };
+ };
+
gpio0: gpio@230 {
compatible = "fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 50f9b527cd..c2a156ea8e 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -2,7 +2,7 @@
/*
* NXP ls1028a SOC common device tree source
*
- * Copyright 2019-2020 NXP
+ * Copyright 2019-2021 NXP
*
*/
@@ -123,6 +123,45 @@
0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+ crypto: crypto@800 {
+ compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
+ fsl,sec-era = <10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x800 0x10>;
+ reg = <0x00 0x800 0x0 0x10>;
+ interrupts = ;
+ dma-coherent;
+
+ sec_jr0: jr@1 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x1 0x1>;
+ interrupts = ;
+ };
+
+ sec_jr1: jr@2 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x2 0x1>;
+ interrupts = ;
+ };
+
+ sec_jr2: jr@3 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-r
[PATCH v3 11/16] crypto/fsl: Fix kick_trng
From: Ye Li
fix hwrng performance issue in kernel.
Signed-off-by: Ye Li
Acked-by: Gaurav Jain >
---
drivers/crypto/fsl/jr.c | 109 ++--
include/fsl_sec.h | 1 +
2 files changed, 94 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 0bfdf9070f..72f09a1d8b 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -602,30 +602,107 @@ static u8 get_rng_vid(ccsr_sec_t *sec)
*/
static void kick_trng(int ent_delay, ccsr_sec_t *sec)
{
+ u32 samples = 512; /* number of bits to generate and test */
+ u32 mono_min = 195;
+ u32 mono_max = 317;
+ u32 mono_range = mono_max - mono_min;
+ u32 poker_min = 1031;
+ u32 poker_max = 1600;
+ u32 poker_range = poker_max - poker_min + 1;
+ u32 retries= 2;
+ u32 lrun_max = 32;
+ s32 run_1_min = 27;
+ s32 run_1_max = 107;
+ s32 run_1_range = run_1_max - run_1_min;
+ s32 run_2_min = 7;
+ s32 run_2_max = 62;
+ s32 run_2_range = run_2_max - run_2_min;
+ s32 run_3_min = 0;
+ s32 run_3_max = 39;
+ s32 run_3_range = run_3_max - run_3_min;
+ s32 run_4_min = -1;
+ s32 run_4_max = 26;
+ s32 run_4_range = run_4_max - run_4_min;
+ s32 run_5_min = -1;
+ s32 run_5_max = 18;
+ s32 run_5_range = run_5_max - run_5_min;
+ s32 run_6_min = -1;
+ s32 run_6_max = 17;
+ s32 run_6_range = run_6_max - run_6_min;
+ u32 val;
+
struct rng4tst __iomem *rng =
(struct rng4tst __iomem *)&sec->rng;
- u32 val;
- /* put RNG4 into program mode */
- sec_setbits32(&rng->rtmctl, RTMCTL_PRGM);
- /* rtsdctl bits 0-15 contain "Entropy Delay, which defines the
-* length (in system clocks) of each Entropy sample taken
-* */
+ /* Put RNG in program mode */
+ /* Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
+* properly invalidate the entropy in the entropy register and
+* force re-generation.
+*/
+ sec_setbits32(&rng->rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
+
+ /* Configure the RNG Entropy Delay
+* Performance-wise, it does not make sense to
+* set the delay to a value that is lower
+* than the last one that worked (i.e. the state handles
+* were instantiated properly. Thus, instead of wasting
+* time trying to set the values controlling the sample
+* frequency, the function simply returns.
+*/
val = sec_in32(&rng->rtsdctl);
- val = (val & ~RTSDCTL_ENT_DLY_MASK) |
- (ent_delay << RTSDCTL_ENT_DLY_SHIFT);
+ val &= RTSDCTL_ENT_DLY_MASK;
+ val >>= RTSDCTL_ENT_DLY_SHIFT;
+ if (ent_delay < val) {
+ /* Put RNG4 into run mode */
+ sec_clrbits32(&rng->rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
+ return;
+ }
+
+ val = (ent_delay << RTSDCTL_ENT_DLY_SHIFT) | samples;
sec_out32(&rng->rtsdctl, val);
- /* min. freq. count, equal to 1/4 of the entropy sample length */
- sec_out32(&rng->rtfreqmin, ent_delay >> 2);
- /* disable maximum frequency count */
- sec_out32(&rng->rtfreqmax, RTFRQMAX_DISABLE);
+
/*
-* select raw sampling in both entropy shifter
+* Recommended margins (min,max) for freq. count:
+* freq_mul = RO_freq / TRNG_clk_freq
+* rtfrqmin = (ent_delay x freq_mul) >> 1;
+* rtfrqmax = (ent_delay x freq_mul) << 3;
+* Given current deployments of CAAM in i.MX SoCs, and to simplify
+* the configuration, we consider [1,16] to be a safe interval
+* for the freq_mul and the limits of the interval are used to compute
+* rtfrqmin, rtfrqmax
+*/
+ sec_out32(&rng->rtfreqmin, ent_delay >> 1);
+ sec_out32(&rng->rtfreqmax, ent_delay << 7);
+
+ sec_out32(&rng->rtscmisc, (retries << 16) | lrun_max);
+ sec_out32(&rng->rtpkrmax, poker_max);
+ sec_out32(&rng->rtpkrrng, poker_range);
+ sec_out32(&rng->rsvd1[0], (mono_range << 16) | mono_max);
+ sec_out32(&rng->rsvd1[1], (run_1_range << 16) | run_1_max);
+ sec_out32(&rng->rsvd1[2], (run_2_range << 16) | run_2_max);
+ sec_out32(&rng->rsvd1[3], (run_3_range << 16) | run_3_max);
+ sec_out32(&rng->rsvd1[4], (run_4_range << 16) | run_4_max);
+ sec_out32(&rng->rsvd1[5], (run_5_range << 16) | run_5_max);
+ sec_out32(&rng->rsvd1[6], (run_6_range << 16) | run_6_max);
+
+ val = sec_in32(&rng->rtmctl);
+ /*
+* Select raw sampling in both entropy shifter
* and statistical checker
*/
- sec_setbits32(&rng->rtmctl, RTMCTL_SAMP_MODE_RAW_ES_SC);
- /* put RNG4 into run mode */
- sec_clrbits32(&rng->rtmctl, RTMCTL_PRGM);
+ val &= ~RTMCTL_SAMP_MODE_INVALID;
+ val |= RTMCTL_SAMP_MODE
[PATCH v3 10/16] crypto/fsl: i.MX8: Enable Job ring driver model in SPL and U-Boot.
i.MX8(QM/QXP) - added support for JR driver model.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Signed-off-by: Horia Geantă
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 3 +++
arch/arm/include/asm/arch-imx8/imx-regs.h | 5 -
arch/arm/mach-imx/cmd_dek.c | 1 +
arch/arm/mach-imx/imx8/Kconfig| 9 +
arch/arm/mach-imx/imx8/cpu.c | 16 ++-
board/freescale/imx8qm_mek/spl.c | 6 --
board/freescale/imx8qxp_mek/spl.c | 6 --
drivers/crypto/fsl/Kconfig| 2 +-
drivers/crypto/fsl/jr.c | 24 +++
include/fsl_sec.h | 12 +---
10 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 51dbc3581b..05aa2efb72 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -785,6 +785,9 @@ config ARCH_LPC32XX
config ARCH_IMX8
bool "NXP i.MX8 platform"
select ARM64
+ select SYS_FSL_HAS_SEC
+ select SYS_FSL_SEC_COMPAT_4
+ select SYS_FSL_SEC_LE
select DM
select GPIO_EXTRA_HEADER
select OF_CONTROL
diff --git a/arch/arm/include/asm/arch-imx8/imx-regs.h
b/arch/arm/include/asm/arch-imx8/imx-regs.h
index ed6e05e556..2d64b0604b 100644
--- a/arch/arm/include/asm/arch-imx8/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8/imx-regs.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#ifndef __ASM_ARCH_IMX8_REGS_H__
@@ -47,4 +47,7 @@
#define USB_BASE_ADDR 0x5b0d
#define USB_PHY0_BASE_ADDR 0x5b10
+#define CONFIG_SYS_FSL_SEC_ADDR (0x3140)
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 1
+
#endif /* __ASM_ARCH_IMX8_REGS_H__ */
diff --git a/arch/arm/mach-imx/cmd_dek.c b/arch/arm/mach-imx/cmd_dek.c
index 89da89c51d..04c4b20a84 100644
--- a/arch/arm/mach-imx/cmd_dek.c
+++ b/arch/arm/mach-imx/cmd_dek.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index b43739e5c6..9a20ebe84e 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -8,6 +8,7 @@ config AHAB_BOOT
config IMX8
bool
+ select HAS_CAAM
config MU_BASE_SPL
hex "MU base address used in SPL"
@@ -72,6 +73,10 @@ config TARGET_IMX8QM_MEK
bool "Support i.MX8QM MEK board"
select BOARD_LATE_INIT
select IMX8QM
+ select FSL_CAAM
+ select FSL_BLOB
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_CONGA_QMX8
bool "Support congatec conga-QMX8 board"
@@ -89,6 +94,10 @@ config TARGET_IMX8QXP_MEK
bool "Support i.MX8QXP MEK board"
select BOARD_LATE_INIT
select IMX8QXP
+ select FSL_CAAM
+ select FSL_BLOB
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
endchoice
diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 02db322f51..86ced79bb7 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -89,6 +89,20 @@ int arch_cpu_init_dm(void)
return 0;
}
+#if defined(CONFIG_ARCH_MISC_INIT)
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
+
int print_bootinfo(void)
{
enum boot_device bt_dev = get_boot_device();
diff --git a/board/freescale/imx8qm_mek/spl.c b/board/freescale/imx8qm_mek/spl.c
index 944ba745c0..332a662dee 100644
--- a/board/freescale/imx8qm_mek/spl.c
+++ b/board/freescale/imx8qm_mek/spl.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
- * SPDX-License-Identifier:GPL-2.0+
*/
#include
@@ -24,6 +24,8 @@ void spl_board_init(void)
{
struct udevice *dev;
+ uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(imx8_scu), &dev);
+
uclass_find_first_device(UCLASS_MISC, &dev);
for (; dev; uclass_find_next_device(&dev)) {
diff --git a/board/freescale/imx8qxp_mek/spl.c
b/board/freescale/imx8qxp_mek/spl.c
index ae6b64ff6e..2fa6840056 100644
--- a/board/freescale/imx8qxp_mek/spl.c
+++ b/board/freescale/imx8qxp_mek/spl.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
- * SPDX-License-Identifier:GPL-2.0+
*/
#include
@@ -39,6 +39,8 @@ void spl_board_init(void)
{
struct udevice *dev;
+ uclass_get_device_by_driver(UCLASS
[PATCH v3 09/16] i.MX8: Add crypto node in device tree
i.MX8(QM/QXP) - updated device tree for supporting DM in SPL.
disabled use of JR1 in SPL and uboot, as JR1 is reserved
for SECO FW.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/dts/fsl-imx8dx.dtsi | 61 +++-
arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 34 -
arch/arm/dts/fsl-imx8qm.dtsi | 61 +++-
arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 34 -
4 files changed, 186 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/fsl-imx8dx.dtsi b/arch/arm/dts/fsl-imx8dx.dtsi
index 7d95cf0b7d..63a56699b5 100644
--- a/arch/arm/dts/fsl-imx8dx.dtsi
+++ b/arch/arm/dts/fsl-imx8dx.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -261,6 +261,30 @@
power-domains = <&pd_dma>;
};
};
+
+ pd_caam: PD_CAAM {
+ compatible = "nxp,imx8-pd";
+ reg = ;
+ #power-domain-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_caam_jr1: PD_CAAM_JR1 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_caam>;
+ };
+ pd_caam_jr2: PD_CAAM_JR2 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_caam>;
+ };
+ pd_caam_jr3: PD_CAAM_JR3 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_caam>;
+ };
+ };
};
i2c0: i2c@5a80 {
@@ -609,6 +633,41 @@
};
};
};
+
+ crypto: caam@0x3140 {
+ compatible = "fsl,sec-v4.0";
+ reg = <0 0x3140 0 0x40>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x3140 0x40>;
+ fsl,first-jr-index = <2>;
+ fsl,sec-era = <9>;
+
+ sec_jr1: jr1@0x2 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2 0x1000>;
+ interrupts = ;
+ power-domains = <&pd_caam_jr1>;
+ status = "disabled";
+ };
+
+ sec_jr2: jr2@3 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3 0x1000>;
+ interrupts = ;
+ power-domains = <&pd_caam_jr2>;
+ status = "okay";
+ };
+
+ sec_jr3: jr3@4 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4 0x1000>;
+ interrupts = ;
+ power-domains = <&pd_caam_jr3>;
+ status = "okay";
+ };
+ };
};
&A35_0 {
diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
index 9e0d264b71..a95209e141 100644
--- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
+++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
&{/imx8qm-pm} {
@@ -80,6 +80,22 @@
u-boot,dm-spl;
};
+&pd_caam {
+ u-boot,dm-spl;
+};
+
+&pd_caam_jr1 {
+ u-boot,dm-spl;
+};
+
+&pd_caam_jr2 {
+ u-boot,dm-spl;
+};
+
+&pd_caam_jr3 {
+ u-boot,dm-spl;
+};
+
&gpio0 {
u-boot,dm-spl;
};
@@ -126,3 +142,19 @@
sd-uhs-sdr104;
sd-uhs-ddr50;
};
+
+&crypto {
+ u-boot,dm-spl;
+};
+
+&sec_jr1 {
+ u-boot,dm-spl;
+};
+
+&sec_jr2 {
+ u-boot,dm-spl;
+};
+
+&sec_jr3 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
index 88aeaf65b3..517fb13cad 100644
--- a/arch/arm/dts/fsl-imx8qm.dtsi
+++ b/arch/arm/dts/fsl-imx8qm.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -235,6 +235,30 @@
wakeup-irq = <349>;
};
};
+
+ pd_caam: PD_CAAM {
+ compatible = "nxp,imx8-pd";
+ reg = ;
+ #power-domain-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_caam_jr1: PD_CAAM_JR1 {
+ reg = ;
+
[PATCH v3 08/16] i.MX7ULP: Enable Job ring driver model in U-Boot.
added crypto node in device tree.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/dts/imx7ulp.dtsi| 24
arch/arm/mach-imx/mx7ulp/Kconfig | 4
arch/arm/mach-imx/mx7ulp/soc.c | 16
4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1a868c803..51dbc3581b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -848,7 +848,7 @@ config ARCH_MX7ULP
bool "NXP MX7ULP"
select CPU_V7A
select GPIO_EXTRA_HEADER
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
select ROM_UNIFIED_SECTIONS
diff --git a/arch/arm/dts/imx7ulp.dtsi b/arch/arm/dts/imx7ulp.dtsi
index 7bcd2cc346..494b9d98b2 100644
--- a/arch/arm/dts/imx7ulp.dtsi
+++ b/arch/arm/dts/imx7ulp.dtsi
@@ -1,5 +1,6 @@
/*
* Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -198,6 +199,29 @@
};
};
+ crypto: crypto@4024 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x4024 0x1>;
+ ranges = <0 0x4024 0x1>;
+ clocks = <&clks IMX7ULP_CLK_CAAM>,
+<&clks IMX7ULP_CLK_NIC1_BUS_DIV>;
+ clock-names = "aclk", "ipg";
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ };
+ };
+
tpm5: tpm@4026 {
compatible = "fsl,imx7ulp-tpm";
reg = <0x4026 0x1000>;
diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index 2ffac9cf7c..0d9f8ffed9 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -25,6 +25,10 @@ config TARGET_MX7ULP_EVK
bool "Support mx7ulp EVK board"
select MX7ULP
select SYS_ARCH_TIMER
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
endchoice
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 320f24dd29..1cfc751bdc 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#define PMC0_BASE_ADDR 0x410a1000
#define PMC0_CTRL 0x28
@@ -79,6 +81,20 @@ int arch_cpu_init(void)
return 0;
}
+#if defined(CONFIG_ARCH_MISC_INIT)
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_BOARD_POSTCLK_INIT
int board_postclk_init(void)
{
--
2.17.1
[PATCH v3 07/16] i.MX7: Enable Job ring driver model in U-Boot.
i.MX7D - added support for JR driver model.
removed sec_init() call, sec is initialized based on
job ring information processed from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/mach-imx/mx7/Kconfig | 3 +++
arch/arm/mach-imx/mx7/soc.c | 11 +++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f50941e056..c1a868c803 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -860,7 +860,7 @@ config ARCH_MX7
select ARCH_MISC_INIT
select CPU_V7A
select GPIO_EXTRA_HEADER
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
imply BOARD_EARLY_INIT_F
diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig
index adedc01164..b82338e2cc 100644
--- a/arch/arm/mach-imx/mx7/Kconfig
+++ b/arch/arm/mach-imx/mx7/Kconfig
@@ -60,6 +60,9 @@ config TARGET_MX7DSABRESD
select DM_THERMAL
select MX7D
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
config TARGET_PICO_IMX7D
bool "pico-imx7d"
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index fda25ba66a..26b00bc93f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -18,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -336,6 +336,9 @@ int arch_cpu_init(void)
#ifdef CONFIG_ARCH_MISC_INIT
int arch_misc_init(void)
{
+ struct udevice *dev;
+ int ret;
+
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
if (is_mx7d())
env_set("soc", "imx7d");
@@ -343,9 +346,9 @@ int arch_misc_init(void)
env_set("soc", "imx7s");
#endif
-#ifdef CONFIG_FSL_CAAM
- sec_init();
-#endif
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
return 0;
}
--
2.17.1
[PATCH v3 06/16] i.MX6: Enable Job ring driver model in U-Boot.
i.MX6,i.MX6SX,i.MX6UL - added support for JR driver model.
removed sec_init() call, sec is initialized based on
job ring information processed from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/mach-imx/mx6/Kconfig | 20
arch/arm/mach-imx/mx6/soc.c | 12
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 515c3020fa..8553a23309 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -346,6 +346,10 @@ config TARGET_MX6SABREAUTO
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SABRESD
bool "mx6sabresd"
@@ -356,6 +360,10 @@ config TARGET_MX6SABRESD
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SLEVK
bool "mx6slevk"
@@ -378,6 +386,10 @@ config TARGET_MX6SXSABRESD
select DM
select DM_THERMAL
select SUPPORT_SPL
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SXSABREAUTO
bool "mx6sxsabreauto"
@@ -396,6 +408,10 @@ config TARGET_MX6UL_9X9_EVK
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6UL_14X14_EVK
bool "mx6ul_14x14_evk"
@@ -405,6 +421,10 @@ config TARGET_MX6UL_14X14_EVK
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6UL_ENGICAM
bool "Support Engicam GEAM6UL/Is.IoT"
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index aacfc854a2..fa6c3778bb 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -4,6 +4,7 @@
* Sascha Hauer, Pengutronix
*
* (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -23,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
@@ -734,9 +734,13 @@ static void setup_serial_number(void)
int arch_misc_init(void)
{
-#ifdef CONFIG_FSL_CAAM
- sec_init();
-#endif
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
setup_serial_number();
return 0;
}
--
2.17.1
[PATCH v3 05/16] mx6sabre: Remove unnecessary SPL configs
From: Ye Li Because we don't use SPL_DM on mx6sabresd and mx6sabreauto, so it is unnecessary to have SPL DTB related configs and SPL_OF_CONTROL enabled. Signed-off-by: Ye Li Reviewed-by: Fabio Estevam Reviewed-by: Gaurav Jain --- configs/mx6sabreauto_defconfig | 2 -- configs/mx6sabresd_defconfig | 4 2 files changed, 6 deletions(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index 1059c5a8a3..f65f2d7ed0 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -57,10 +57,8 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="imx6dl-sabreauto imx6q-sabreauto imx6qp-sabreauto" CONFIG_MULTI_DTB_FIT=y -CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig index 61e9054717..29df2bbb33 100644 --- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -60,12 +60,8 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" CONFIG_MULTI_DTB_FIT=y -CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" -CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.17.1
[PATCH v3 04/16] crypto/fsl: i.MX8M: Enable Job ring driver model in SPL and U-Boot.
i.MX8MM/MN/MP/MQ - added support for JR driver model.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/arch-imx8m/imx-regs.h | 1 +
arch/arm/mach-imx/imx8m/Kconfig| 23 ++
arch/arm/mach-imx/imx8m/soc.c | 10 +-
board/freescale/imx8mm_evk/spl.c | 9 -
board/freescale/imx8mn_evk/spl.c | 8 ++--
board/freescale/imx8mp_evk/spl.c | 13 ++--
board/freescale/imx8mq_evk/spl.c | 9 +++--
drivers/crypto/fsl/jr.c| 14 ++---
scripts/config_whitelist.txt | 1 +
10 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5bd3284cd..f50941e056 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -794,7 +794,7 @@ config ARCH_IMX8M
bool "NXP i.MX8M platform"
select ARM64
select GPIO_EXTRA_HEADER
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
select DM
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index b800da13a1..ff8de53f67 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -72,6 +72,7 @@
#define CONFIG_SYS_FSL_SEC_ADDR (CAAM_IPS_BASE_ADDR + \
CONFIG_SYS_FSL_SEC_OFFSET)
#define CONFIG_SYS_FSL_JR0_OFFSET (0x1000)
+#define CONFIG_SYS_FSL_JR1_OFFSET (0x2000)
#define CONFIG_SYS_FSL_JR0_ADDR (CONFIG_SYS_FSL_SEC_ADDR + \
CONFIG_SYS_FSL_JR0_OFFSET)
#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 1
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index ccaf106be5..3fbdd5c233 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -38,6 +38,11 @@ config TARGET_IMX8MQ_EVK
bool "imx8mq_evk"
select IMX8MQ
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MQ_PHANBELL
bool "imx8mq_phanbell"
@@ -50,6 +55,11 @@ config TARGET_IMX8MM_EVK
select IMX8MM
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MM_ICORE_MX8MM
bool "Engicam i.Core MX8M Mini SOM"
@@ -81,6 +91,10 @@ config TARGET_IMX8MN_EVK
select IMX8MN
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MN_DDR4_EVK
bool "imx8mn DDR4 EVK board"
@@ -88,6 +102,10 @@ config TARGET_IMX8MN_DDR4_EVK
select IMX8MN
select SUPPORT_SPL
select IMX8M_DDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MP_EVK
bool "imx8mp LPDDR4 EVK board"
@@ -95,6 +113,11 @@ config TARGET_IMX8MP_EVK
select IMX8MP
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_PICO_IMX8MQ
bool "Support Technexion Pico iMX8MQ"
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index f2ddc834d4..0fe28f4971 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017-2019 NXP
+ * Copyright 2017-2019, 2021 NXP
*
* Peng Fan
*/
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1187,6 +1188,13 @@ static void acquire_buildinfo(void)
int arch_misc_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
acquire_buildinfo();
return 0;
diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c
index 4ef7f6f180..c81128f442 100644
--- a/board/freescale/imx8mm_evk/spl.c
+++ b/board/freescale/imx8mm_evk/spl.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include
@@ -51,6 +51,13 @@ static void spl_dram_init(void)
void spl_board_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
&dev);
+ if
[PATCH v3 03/16] i.MX8M: crypto: updated device tree for supporting DM in SPL
disabled use of JR0 in SPL and uboot, as JR0 is reserved
for secure boot.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mm.dtsi | 1 +
arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mn.dtsi | 1 +
arch/arm/dts/imx8mp-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mp.dtsi | 1 +
arch/arm/dts/imx8mq.dtsi | 1 +
7 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index f200afac9f..3c2502cbba 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include "imx8mm-u-boot.dtsi"
@@ -72,6 +72,22 @@
u-boot,dm-spl;
};
+&crypto {
+ u-boot,dm-spl;
+};
+
+&sec_jr0 {
+ u-boot,dm-spl;
+};
+
+&sec_jr1 {
+ u-boot,dm-spl;
+};
+
+&sec_jr2 {
+ u-boot,dm-spl;
+};
+
&usdhc1 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
index b142b80734..00bf3a 100644
--- a/arch/arm/dts/imx8mm.dtsi
+++ b/arch/arm/dts/imx8mm.dtsi
@@ -824,6 +824,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
index 1d3844437d..b462d24eb2 100644
--- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
/ {
@@ -104,6 +104,22 @@
u-boot,dm-spl;
};
+&crypto {
+ u-boot,dm-spl;
+};
+
+&sec_jr0 {
+ u-boot,dm-spl;
+};
+
+&sec_jr1 {
+ u-boot,dm-spl;
+};
+
+&sec_jr2 {
+ u-boot,dm-spl;
+};
+
&usdhc1 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mn.dtsi b/arch/arm/dts/imx8mn.dtsi
index edcb415b53..1820a5af37 100644
--- a/arch/arm/dts/imx8mn.dtsi
+++ b/arch/arm/dts/imx8mn.dtsi
@@ -822,6 +822,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index 2abcf1f03d..5415d5b617 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include "imx8mp-u-boot.dtsi"
@@ -67,6 +67,22 @@
u-boot,dm-spl;
};
+&crypto {
+ u-boot,dm-spl;
+};
+
+&sec_jr0 {
+ u-boot,dm-spl;
+};
+
+&sec_jr1 {
+ u-boot,dm-spl;
+};
+
+&sec_jr2 {
+ u-boot,dm-spl;
+};
+
&i2c1 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
index c2d51a46cb..57b01c3a57 100644
--- a/arch/arm/dts/imx8mp.dtsi
+++ b/arch/arm/dts/imx8mp.dtsi
@@ -624,6 +624,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mq.dtsi b/arch/arm/dts/imx8mq.dtsi
index a44f729d0e..ecab44ca13 100644
--- a/arch/arm/dts/imx8mq.dtsi
+++ b/arch/arm/dts/imx8mq.dtsi
@@ -955,6 +955,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
--
2.17.1
[PATCH v3 02/16] crypto/fsl: Add CAAM support for bkek, random number generation
added api and descriptor for blob key encryption key(bkek) generation.
added api for random number generation.
Signed-off-by: Gaurav Jain
Signed-off-by: Ji Luo
Reviewed-by: Ye Li
---
drivers/crypto/fsl/desc.h | 5 +++
drivers/crypto/fsl/fsl_blob.c | 82 +++
drivers/crypto/fsl/jobdesc.c | 20 +++--
drivers/crypto/fsl/jobdesc.h | 4 ++
4 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/fsl/desc.h b/drivers/crypto/fsl/desc.h
index 5705c4f944..5958ebd3ac 100644
--- a/drivers/crypto/fsl/desc.h
+++ b/drivers/crypto/fsl/desc.h
@@ -4,6 +4,7 @@
* Definitions to support CAAM descriptor instruction generation
*
* Copyright 2008-2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
* Based on desc.h file in linux drivers/crypto/caam
*/
@@ -15,6 +16,7 @@
#define KEY_BLOB_SIZE 32
#define MAC_SIZE 16
+#define BKEK_SIZE 32
/* Max size of any CAAM descriptor in 32-bit words, inclusive of header */
#define MAX_CAAM_DESCSIZE 64
@@ -463,6 +465,9 @@
#define OP_PROTINFO_HASH_SHA3840x0200
#define OP_PROTINFO_HASH_SHA5120x0280
+/* PROTINFO fields for Blob Operations */
+#define OP_PROTINFO_MKVB 0x0002
+
/* For non-protocol/alg-only op commands */
#define OP_ALG_TYPE_SHIFT 24
#define OP_ALG_TYPE_MASK (0x7 << OP_ALG_TYPE_SHIFT)
diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
index e8202cc569..e8bc009daf 100644
--- a/drivers/crypto/fsl/fsl_blob.c
+++ b/drivers/crypto/fsl/fsl_blob.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
*/
@@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
return ret;
}
+int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
+{
+ int ret, size;
+ u32 *desc;
+
+ if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
+ !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
+ puts("Error: derive_bkek: Address arguments are not
aligned!\n");
+ return -EINVAL;
+ }
+
+ printf("\nBlob key encryption key(bkek)\n");
+ desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
+ if (!desc) {
+ printf("Not enough memory for descriptor allocation\n");
+ return -ENOMEM;
+ }
+
+ size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)key_mod, (unsigned long)key_mod +
size);
+
+ /* construct blob key encryption key(bkek) derive descriptor */
+ inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod, key_sz);
+
+ size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
+ size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
+ invalidate_dcache_range((unsigned long)bkek_buf,
+ (unsigned long)bkek_buf + size);
+
+ /* run descriptor */
+ ret = run_descriptor_jr(desc);
+ if (ret < 0) {
+ printf("Error: %s failed 0x%x\n", __func__, ret);
+ } else {
+ invalidate_dcache_range((unsigned long)bkek_buf,
+ (unsigned long)bkek_buf + size);
+ puts("derive bkek successful.\n");
+ }
+
+ free(desc);
+ return ret;
+}
+
+int hwrng_generate(u8 *dst, u32 len)
+{
+ int ret, size;
+ u32 *desc;
+
+ if (!IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
+ puts("Error: caam_hwrng_test: Address arguments are not
aligned!\n");
+ return -EINVAL;
+ }
+
+ printf("\nRNG generate\n");
+ desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
+ if (!desc) {
+ printf("Not enough memory for descriptor allocation\n");
+ return -ENOMEM;
+ }
+
+ inline_cnstr_jobdesc_rng(desc, dst, len);
+
+ size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
+ size = ALIGN(len, ARCH_DMA_MINALIGN);
+ invalidate_dcache_range((unsigned long)dst, (unsigned long)dst + size);
+
+ ret = run_descriptor_jr(desc);
+ if (ret < 0) {
+ printf("Error: RNG generate failed 0x%x\n", ret);
+ } else {
+ invalidate_dcache_range((unsigned long)dst,
+ (unsigned long)dst + size);
+ puts("RNG generation successful.\n");
+ }
+
+ free(desc);
+ return ret;
+}
+
#ifdef CONFIG_CMD_DEKBLOB
int blob_dek(const u8 *src, u8 *dst, u8 len)
{
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index c350b32856..d58937c284 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdes
[PATCH v3 01/16] crypto/fsl: Add support for CAAM Job ring driver model
added device tree support for job ring driver.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
cmd/Kconfig | 1 +
drivers/crypto/fsl/Kconfig | 7 +
drivers/crypto/fsl/Makefile | 3 +-
drivers/crypto/fsl/jr.c | 318
drivers/crypto/fsl/jr.h | 14 ++
5 files changed, 233 insertions(+), 110 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3a857b3f6e..9077e6668d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1985,6 +1985,7 @@ config CMD_AES
config CMD_BLOB
bool "Enable the 'blob' command"
+ select FSL_BLOB
depends on !MX6ULL && !MX6SLL && !MX6SL
select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
help
diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
index 94ff540111..ab59d516f8 100644
--- a/drivers/crypto/fsl/Kconfig
+++ b/drivers/crypto/fsl/Kconfig
@@ -66,4 +66,11 @@ config FSL_CAAM_RNG
using the prediction resistance flag which means the DRGB is
reseeded from the TRNG every time random data is generated.
+config FSL_BLOB
+bool "Enable Blob Encap/Decap, Blob KEK support"
+ help
+ Enable support for the hardware based crytographic blob encap/decap
+ module of the CAAM. blobs can be safely placed into non-volatile
+ storage. blobs can only be decapsulated by the SoC that created it.
+ Enable support for blob key encryption key generation.
endif
diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
index f9c3ccecfc..4a1f719fa1 100644
--- a/drivers/crypto/fsl/Makefile
+++ b/drivers/crypto/fsl/Makefile
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright 2014 Freescale Semiconductor, Inc.
+# Copyright 2021 NXP
obj-y += sec.o
obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
-obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
+obj-$(CONFIG_FSL_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 22b649219e..bec4953f6d 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2008-2014 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
* Based on CAAM driver in drivers/crypto/caam in Linux
*/
@@ -11,7 +11,6 @@
#include
#include
#include
-#include "fsl_sec.h"
#include "jr.h"
#include "jobdesc.h"
#include "desc_constr.h"
@@ -21,8 +20,11 @@
#include
#include
#endif
+#include
#include
#include
+#include
+#include
#define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
#define CIRC_SPACE(head, tail, size) CIRC_CNT((tail), (head) + 1, (size))
@@ -35,20 +37,30 @@ uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
#endif
};
+#if CONFIG_IS_ENABLED(DM)
+struct udevice *caam_dev;
+#else
#define SEC_ADDR(idx) \
(ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
#define SEC_JR0_ADDR(idx) \
(ulong)(SEC_ADDR(idx) + \
(CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
+struct caam_regs caam_st;
+#endif
-struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
+static inline u32 jr_start_reg(u8 jrid)
+{
+ return (1 << jrid);
+}
-static inline void start_jr0(uint8_t sec_idx)
+#ifndef CONFIG_ARCH_IMX8
+static inline void start_jr(struct caam_regs *caam)
{
- ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
+ ccsr_sec_t *sec = caam->sec;
u32 ctpr_ms = sec_in32(&sec->ctpr_ms);
u32 scfgr = sec_in32(&sec->scfgr);
+ u32 jrstart = jr_start_reg(caam->jrid);
if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
/* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or
@@ -56,23 +68,17 @@ static inline void start_jr0(uint8_t sec_idx)
*/
if ((ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR) ||
(scfgr & SEC_SCFGR_VIRT_EN))
- sec_out32(&sec->jrstartr, CONFIG_JRSTARTR_JR0);
+ sec_out32(&sec->jrstartr, jrstart);
} else {
/* VIRT_EN_INCL = 0 && VIRT_EN_POR_VALUE = 1 */
if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR)
- sec_out32(&sec->jrstartr, CONFIG_JRSTARTR_JR0);
+ sec_out32(&sec->jrstartr, jrstart);
}
}
+#endif
-static inline void jr_reset_liodn(uint8_t sec_idx)
-{
- ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
- sec_out32(&sec->jrliodnr[0].ls, 0);
-}
-
-static inline void jr_disable_irq(uint8_t sec_idx)
+static inline void jr_disable_irq(struct jr_regs *regs)
{
- struct jr_regs *regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
uint32_t jrcfg = sec_in32(®s->jrcfg1)
[PATCH v3 00/16] Add CAAM driver model support
This patchset adds the support for following: 1) CAAM Driver model for all i.MX, layerscape, PPC platforms. 2) Added crypto node in device tree files. 3) CAAM support for blob key encryption key(bkek), random number generation. 4) fix build issue for mx6sabre: Remove SPL DTB related configs and SPL_OF_CONTROL. 5) fixed hwrng performance issue in kernel. i.MX platforms: i.MX6, i.MX7, i.MX7ULP, i.MX8MM/MN/MP/MQ, i.MX8QM/QXP Layerscape platforms: LS1021, LS1012, LS1028, LS1043, LS1046, LS1088, LS2088, LX2160, LX2162 Powerpc platforms: P3041, P4080, P5040, P2041, T1024, T1042, T2080, T4240 Gaurav Jain (14): crypto/fsl: Add support for CAAM Job ring driver model crypto/fsl: Add CAAM support for bkek, random number generation i.MX8M: crypto: updated device tree for supporting DM in SPL crypto/fsl: i.MX8M: Enable Job ring driver model in SPL and U-Boot. i.MX6: Enable Job ring driver model in U-Boot. i.MX7: Enable Job ring driver model in U-Boot. i.MX7ULP: Enable Job ring driver model in U-Boot. i.MX8: Add crypto node in device tree crypto/fsl: i.MX8: Enable Job ring driver model in SPL and U-Boot. Layerscape: Add crypto node in device tree Layerscape: Enable Job ring driver model in U-Boot. PPC: Add crypto node in device tree PPC: Enable Job ring driver model in U-Boot update CAAM MAINTAINER Ye Li (2): mx6sabre: Remove unnecessary SPL configs crypto/fsl: Fix kick_trng MAINTAINERS | 7 + arch/arm/Kconfig | 9 +- arch/arm/cpu/armv7/ls102xa/Kconfig| 4 + arch/arm/cpu/armv7/ls102xa/cpu.c | 16 + arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 + arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 10 +- arch/arm/dts/fsl-imx8dx.dtsi | 61 ++- arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 34 +- arch/arm/dts/fsl-imx8qm.dtsi | 61 ++- arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 34 +- arch/arm/dts/fsl-ls1012a.dtsi | 46 +- arch/arm/dts/fsl-ls1028a.dtsi | 41 +- arch/arm/dts/fsl-ls1043a.dtsi | 45 +- arch/arm/dts/fsl-ls1046a.dtsi | 44 ++ arch/arm/dts/fsl-ls1088a.dtsi | 39 ++ arch/arm/dts/fsl-ls2080a.dtsi | 39 ++ arch/arm/dts/fsl-lx2160a.dtsi | 41 +- arch/arm/dts/imx7ulp.dtsi | 24 + arch/arm/dts/imx8mm-evk-u-boot.dtsi | 18 +- arch/arm/dts/imx8mm.dtsi | 1 + arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18 +- arch/arm/dts/imx8mn.dtsi | 1 + arch/arm/dts/imx8mp-evk-u-boot.dtsi | 18 +- arch/arm/dts/imx8mp.dtsi | 1 + arch/arm/dts/imx8mq.dtsi | 1 + arch/arm/dts/ls1021a.dtsi | 40 ++ arch/arm/include/asm/arch-imx8/imx-regs.h | 5 +- arch/arm/include/asm/arch-imx8m/imx-regs.h| 1 + arch/arm/mach-imx/cmd_dek.c | 1 + arch/arm/mach-imx/imx8/Kconfig| 9 + arch/arm/mach-imx/imx8/cpu.c | 16 +- arch/arm/mach-imx/imx8m/Kconfig | 23 + arch/arm/mach-imx/imx8m/soc.c | 10 +- arch/arm/mach-imx/mx6/Kconfig | 20 + arch/arm/mach-imx/mx6/soc.c | 12 +- arch/arm/mach-imx/mx7/Kconfig | 3 + arch/arm/mach-imx/mx7/soc.c | 11 +- arch/arm/mach-imx/mx7ulp/Kconfig | 4 + arch/arm/mach-imx/mx7ulp/soc.c| 16 + arch/powerpc/cpu/mpc85xx/Kconfig | 44 ++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 17 +- arch/powerpc/dts/p2041si-post.dtsi| 1 + arch/powerpc/dts/p3041si-post.dtsi| 1 + arch/powerpc/dts/p4080si-post.dtsi| 1 + arch/powerpc/dts/p5040si-post.dtsi| 1 + arch/powerpc/dts/qoriq-sec4.0-0.dtsi | 74 +++ arch/powerpc/dts/qoriq-sec4.2-0.dtsi | 83 arch/powerpc/dts/qoriq-sec5.2-0.dtsi | 92 arch/powerpc/dts/t1023si-post.dtsi| 1 + arch/powerpc/dts/t1042si-post.dtsi| 1 + arch/powerpc/dts/t2080si-post.dtsi| 1 + arch/powerpc/dts/t4240si-post.dtsi| 1 + arch/powerpc/include/asm/u-boot-ppc.h | 13 + arch/powerpc/include/asm/u-boot.h | 1 + board/freescale/imx8mm_evk/spl.c | 9 +- board/freescale/imx8mn_evk/spl.c | 8 +- board/freescale/imx8mp_evk/spl.c | 13 +- board/freescale/imx8mq_evk/spl.c | 9 +- board/freescale/imx8qm_mek/spl.c | 6 +- board/freescale/imx8qxp_mek/spl.c | 6 +- board/freescale/ls1012afrdm/ls1012afrdm.c | 7 +- board/freescale/ls1012aqds/ls1012aqds.c | 6 +- board/freescale/ls1012ardb/ls1012ardb.c | 6 +- board/freescale/ls1021aiot/ls1021aiot.c | 6 +- board/frees
Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Mon, Oct 04, 2021 at 09:07:35PM +0300, Ilias Apalodimas wrote:
> On Mon, Oct 04, 2021 at 04:47:53PM +0200, Heinrich Schuchardt wrote:
> >
> >
> > >
>
> [...]
>
> > > My approach in this RFC:
> > >
> > > Due to functional differences in semantics, it would be difficult
> > > to identify "udevice" structure as a handle in UEFI world. Instead, we
> > > will
> > > have to somehow maintain a relationship between a udevice and a handle.
> > >
> > > 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions
> > > Currently, the uclass for paritions is not a UCLASS_BLK.
> > > It can be possible to define partitions as UCLASS_BLK
> > > (with IF_TYPE_PARTION?), but
> > > I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK)
> > > is tightly coupled with 'struct blk_desc' data which is still used
> > > as a "structure to a whole disk" in a lot of interfaces.
> > > (I hope that you understand what it means.)
>
> I think it makes more sense the way it's currently defined. I don;t see a
> point in hiding partitions within UCLASS_BLK
Yeah. But even with my UCLASS_PARTITION, it provides block-level io's
through blk_read/blk_write() APIs.
So someone may wonder why two different type of udevices have the same
interfaces :)
> > >
> > > In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent:
> > > For instance,
> > > UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION
> > >(IF_TYPE_SCSI)|
> > >+- struct blk_desc +- struct disk_part
> > > +- scsi_blk_ops +- blk_part_ops
> > >
> > > 1-2. create partition udevices in the context of device_probe()
> > > part_init() is already called in blk_post_probe(). See the commit
> > > d0851c893706 ("blk: Call part_init() in the post_probe() method").
> > > Why not enumelate partitions as well in there.
> > >
> > > 2. add new block access interfaces, which takes "udevice" as a target
> > > device,
> > > in U-Boot and use those functions to implement efi_disk operations
> > > (i.e. EFI_BLOCK_IO_PROTOCOL).
> > >
> > > 3-1. maintain a bi-directional link by adding
> > > - a UEFI handle pointer in "struct udevice"
> > > - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj")
> >
> > An EFI application can create handles with any combination of protocols,
> > e.g. a handle with both the block IO protocol and the simple network
> > protocol. This means that a udevice cannot be assigned to a handle
> > created by an EFI application.
> >
> > When the EFI application calls ConnectController() for the handle,
> > U-Boot can create child controllers. If U-Boot creates a udevice for
> > such a child controller, it has to store the udevice pointer.
> > lib/efi_driver/efi_block_device.c uses a private data section but you it
> > could be preferable to use a field in struct efi_obj.
> >
>
> I agree with Heinrich here. Basically U-Boot has to be in charge of that.
> Once ConnectController has been called U-Boot should create an 1:1 mapping
> between udevice <-> handle and shouldn't be allowed to change that.
Again, are you sure you're talking about the implementation of efi_disk for
U-Boot's block device (the path(1) in my previous reply to Heinrich)?
-Takahiro Akashi
> > >
> > > 3-2. use device model's post_probe/pre_remove hook to synchronize the
> > > lifetime
> > > of efi_disk objects in UEFI world with the device model.
> > >
> > > 4. I have no answer to issue(4) and (5) yet.
> >
> > 4) A udevice shall only exist for the child controller handle created by
> > U-Boot and not for the controller handle created by an EFI application.
> >
> > 5) The stop() method of the driver binding protocol has to take care of
> > destroying the child controllers and the associated udevices.
> >
> > Best regards
> >
> > Heinrich
>
> Thanks
> /Ilias
Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Mon, Oct 04, 2021 at 04:47:53PM +0200, Heinrich Schuchardt wrote: > > > On 10/4/21 05:44, AKASHI Takahiro wrote: > > # Resending the RFC as some of patches were deplicately submitted. > > # See also > >https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/dm_disk > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > subystem would best be integrated into U-Boot device model. > > In the past, I poposed a couple of patch series, the latest one[1], > > while Heinrich revealed his idea[2], and the approach taken here is > > something between them, with a focus on block device handlings. > > > > # The code is a PoC and not well tested yet. > > > > Disks in UEFI world: > > > > In general in UEFI world, accessing to any device is performed through > > a 'protocol' interface which are installed to (or associated with) the > > device's > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > implemented by either the UEFI system itself or UEFI drivers. > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk > > hereafter). Currently, every efi_disk may have one of two origins: > > a.U-Boot's block devices or related partitions > >(lib/efi_loader/efi_disk.c) > > b.UEFI objects which are implemented as a block device by UEFI drivers. > >(lib/efi_driver/efi_block_device.c) > > > > All the efi_diskss as (a) will be enumelated and created only once at UEFI > > subsystem initialization (efi_disk_register()), which is triggered by > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > "setenv -e" or "efidebug". > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) > > in the corresponding udevice(UCLASS_BLK). > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > services' connect_controller() is executed in UEFI app which, as a (device) > > controller, gives the method to access the device's data, > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > > more details >>> > > Internally, connect_controller() search for UEFI driver that can support > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > then calls the driver's 'bind' interface, which eventually installs > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > >* creating additional partitions efi_disk's, and > >* supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > <<< <<< > > > > Issues: > > === > > 1. While an efi_disk represents a device equally for either a whole disk > > or a partition in UEFI world, the device model treats only a whole > > disk as a real block device or udevice(UCLASS_BLK). > > > > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc > > in plat_data is supposed to be private and not to be accessed outside > > the device model. > > # This issue, though, exists for all the implmenetation of U-Boot > > # file systems as well. > > > > For efi_disk(a), > > 3. A block device can be enumelated dynamically by 'scanning' a device bus > > in U-Boot, but UEFI subsystem is not able to update efi_disks > > accordingly. > > For examples, > > => scsi rescan; efidebug devices > > => usb start; efidebug devices ... (A) > > (A) doesn't show any usb devices detected. > > > > => scsi rescan; efidebug boot add -b 0 TEST scsi 0:1 ... > > => scsi rescan ... (B) > > => bootefi bootmgr ... (C) > > (C) may de-reference a bogus blk_desc pointer which has been freed by > > (B). > > (Please note that "scsi rescan" removes all udevices/blk_desc and then > > re-create them even if nothing is changed on a bus.) > > > > For efi_disk(b), > > 4. A controller (handle), combined with efi_block driver, has no > > corresponding udevice as a parent of efi_disks in DM tree, unlike, say, > > a scsi controller, even though it provides methods for block io > > perations. > > 5. There is no way supported to remove efi_disk's even after > > disconnect_controller() is called. > > > > > > My approach in this RFC: > > > > Due to functional differences in semantics, it would be difficult > > to identify "udevice" structure as a handle in UEFI world. Instead, we will > > have to somehow maintain a relationship between a udevice and a handle. > > > > 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions > > Currently, the uclass for paritions is not a UCLASS_BLK. > > It can be possible to define partitions as UCLASS_BLK > > (with IF_TYPE_PARTION?), but > > I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) > > is tightly coupled with 'struct blk_desc' data which is still used > > as a "structure to a whole disk" in a lot of interfaces. > > (I hope that you understand what it
Re: [resent RFC 14/22] efi_loader: disk: a helper function to create efi_disk objects from udevice
On Mon, Oct 04, 2021 at 09:50:02PM +0300, Ilias Apalodimas wrote:
> On Mon, Oct 04, 2021 at 12:44:22PM +0900, AKASHI Takahiro wrote:
> > Add efi_disk_create() function.
> >
> > Any UEFI handle created by efi_disk_create() can be treated as a efi_disk
> > object, the udevice is either a UCLASS_BLK (a whole raw disk) or
> > UCLASS_PARTITION (a disk partition).
> >
> > So this function is expected to be called every time such an udevice
> > is detected and activated through a device model's "probe" interface.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_loader.h | 2 +
> > lib/efi_loader/efi_disk.c | 92 +++
> > 2 files changed, 94 insertions(+)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index c440962fe522..751fde7fb153 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -517,6 +517,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t
> > debug_disposition,
> > void efi_carve_out_dt_rsv(void *fdt);
> > /* Called by bootefi to make console interface available */
> > efi_status_t efi_console_register(void);
> > +/* Called when a block devices has been probed */
> > +int efi_disk_create(struct udevice *dev);
> > /* Called by bootefi to make all disk storage accessible as EFI objects */
> > efi_status_t efi_disk_register(void);
> > /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index cd5528046251..3fae40e034fb 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -484,6 +485,7 @@ error:
> > return ret;
> > }
> >
> > +#ifndef CONFIG_BLK
> > /**
> > * efi_disk_create_partitions() - create handles and protocols for
> > partitions
> > *
> > @@ -531,6 +533,96 @@ int efi_disk_create_partitions(efi_handle_t parent,
> > struct blk_desc *desc,
> >
> > return disks;
> > }
> > +#endif /* CONFIG_BLK */
> > +
> > +/*
> > + * Create a handle for a whole raw disk
> > + *
> > + * @devuclass device
> > + * @return 0 on success, -1 otherwise
> > + */
> > +static int efi_disk_create_raw(struct udevice *dev)
> > +{
> > + struct efi_disk_obj *disk;
> > + struct blk_desc *desc;
> > + const char *if_typename;
> > + int diskid;
> > + efi_status_t ret;
> > +
> > + desc = dev_get_uclass_plat(dev);
> > + if_typename = blk_get_if_type_name(desc->if_type);
> > + diskid = desc->devnum;
> > +
> > + ret = efi_disk_add_dev(NULL, NULL, if_typename, desc,
> > + diskid, NULL, 0, &disk);
> > + if (ret != EFI_SUCCESS) {
> > + log_err("Adding disk %s%d failed\n", if_typename, diskid);
> > + return -1;
> > + }
> > + disk->dev = dev;
> > + dev->efi_obj = &disk->header;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Create a handle for a disk partition
> > + *
> > + * @devuclass device
> > + * @return 0 on success, -1 otherwise
> > + */
> > +static int efi_disk_create_part(struct udevice *dev)
> > +{
> > + efi_handle_t parent;
> > + struct blk_desc *desc;
> > + const char *if_typename;
> > + struct disk_part *part_data;
> > + struct disk_partition *info;
> > + unsigned int part;
> > + int diskid;
> > + struct efi_device_path *dp = NULL;
> > + struct efi_disk_obj *disk;
> > + efi_status_t ret;
> > +
> > + parent = dev->parent->efi_obj;
> > + desc = dev_get_uclass_plat(dev->parent);
> > + if_typename = blk_get_if_type_name(desc->if_type);
> > + diskid = desc->devnum;
> > +
> > + part_data = dev_get_uclass_plat(dev);
> > + part = part_data->partnum;
> > + info = &part_data->gpt_part_info;
> > +
> > + /* TODO: should not use desc? */
> > + dp = efi_dp_from_part(desc, 0);
> > +
> > + ret = efi_disk_add_dev(parent, dp, if_typename, desc, diskid,
> > + info, part, &disk);
> > + if (ret != EFI_SUCCESS) {
> > + log_err("Adding partition %s%d:%x failed\n",
> > + if_typename, diskid, part);
> > + return -1;
> > + }
> > + disk->dev = dev;
> > + dev->efi_obj = &disk->header;
> > +
> > + return 0;
> > +}
>
> Can't we add a 'bool part' on this one and have a single function?
Yes, but I would like to first discuss how partitions should be treated
in the driver model. Then I will think of unifying related functions.
-Takahiro Akashi
> > +
> > +int efi_disk_create(struct udevice *dev)
> > +{
> > + enum uclass_id id;
> > +
> > + id = device_get_uclass_id(dev);
> > +
> > + if (id == UCLASS_BLK)
> > + return efi_disk_create_raw(dev);
> > +
> > + if (id == UCLASS_PARTITION)
> > + return efi_disk_create_part(dev);
> > +
> > + return -1;
> > +}
> >
> > /**
> > * efi_disk_register() - register block devices
> > --
> > 2.33.0
> >
>
> Reg
Re: [resent RFC 08/22] dm: blk: add UCLASS_PARTITION
On Mon, Oct 04, 2021 at 09:40:21PM +0300, Ilias Apalodimas wrote:
> Hi Akashi-san,
>
> >
>
> [...]
>
> > +int blk_create_partitions(struct udevice *parent)
> > +{
> > + int part, count;
> > + struct blk_desc *desc = dev_get_uclass_plat(parent);
> > + struct disk_partition info;
> > + struct disk_part *part_data;
> > + char devname[32];
> > + struct udevice *dev;
> > + int ret;
> > +
> > + if (!CONFIG_IS_ENABLED(PARTITIONS) ||
> > + !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
> > + return 0;
>
> Would it make more sense to return an error here?
!CONFIG_IS_ENABLED(PARTITIONS) means that a user doesn't want to
use partitions on their system. So simply returning 0 would be fine, I think.
This is kinda equivalence at the caller site:
if (CONFIG_IS_ENABLED(PARTITIONS) &&
CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
ret = blk_create_partitions(dev);
else
debug("We don't care about partitions.");
> > +
> > + /* Add devices for each partition */
> > + for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> > + if (part_get_info(desc, part, &info))
> > + continue;
> > + snprintf(devname, sizeof(devname), "%s:%d", parent->name,
> > +part);
> > +
> > + ret = device_bind_driver(parent, "blk_partition",
> > +strdup(devname), &dev);
> > + if (ret)
> > + return ret;
> > +
> > + part_data = dev_get_uclass_plat(dev);
> > + part_data->partnum = part;
> > + part_data->gpt_part_info = info;
> > + count++;
> > +
> > + device_probe(dev);
>
> Probe can fail.
Theoretically, yes. But as a matter of fact, device_probe() does almost nothing
for UCLASS_PARTITION devices under the proposed implementation here and
I don't expect it will ever fail.
Please note that, as I commented in blk_part_post_probe(), we may want to
call blk_create_partitions() in the future so that we will support
"nested" partitioning in a partition :)
-Takahiro Akashi
> > + }
> > + debug("%s: %d partitions found in %s\n", __func__, count, parent->name);
> > +
> > + return 0;
> > +}
> > +
> > static int blk_post_probe(struct udevice *dev)
> > {
> > if (IS_ENABLED(CONFIG_PARTITIONS) &&
> > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {
> > .post_probe = blk_post_probe,
> > .per_device_plat_auto = sizeof(struct blk_desc),
> > };
> [...]
>
> Regards
> /Ilias
Re: [resent RFC 06/22] sata: call device_probe() after scanning
On Mon, Oct 04, 2021 at 09:45:35PM +0300, Ilias Apalodimas wrote:
> On Mon, Oct 04, 2021 at 12:44:14PM +0900, AKASHI Takahiro wrote:
> > Every time a sata bus/port is scanned and a new device is detected,
> > we want to call device_probe() as it will give us a chance to run additional
> > post-processings for some purposes.
> >
> > In particular, support for creating partitions on a device will be added.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > drivers/ata/dwc_ahsata.c | 10 ++
> > drivers/ata/fsl_sata.c | 11 +++
> > drivers/ata/sata_mv.c| 9 +
> > drivers/ata/sata_sil.c | 12
> > 4 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/ata/dwc_ahsata.c b/drivers/ata/dwc_ahsata.c
> > index 6d42548087b3..6a51c70d1170 100644
> > --- a/drivers/ata/dwc_ahsata.c
> > +++ b/drivers/ata/dwc_ahsata.c
> > @@ -1026,6 +1026,16 @@ int dwc_ahsata_scan(struct udevice *dev)
> > return ret;
> > }
> >
> > + ret = device_probe(bdev);
> > + if (ret < 0) {
> > + debug("Can't probe\n");
> > + /* TODO: undo create */
> > +
> > + device_unbind(bdev);
> > +
> > + return ret;
> > + }
> > +
>
> Patches 2-6 seem to do the same thing for different subsystems. I think
> creating a function for that would make it easier.
Well, the reason why I put those changes in separate commits is
- first, different subsystems are owned by different maintainers, and
- more importantly, different subsystems may have different cleanup
processing required.
There are always extra setups after blk_create_device(), which should
be reverted if device_probe() fails. For instance, sil_unbind_device()
and fsl_unbind_device().
So I would like to leave subsystem owners responsible for that.
-Takahiro Akashi
> > return 0;
> > }
> >
> > diff --git a/drivers/ata/fsl_sata.c b/drivers/ata/fsl_sata.c
> > index e44db0a37458..346e9298b4c5 100644
> > --- a/drivers/ata/fsl_sata.c
> > +++ b/drivers/ata/fsl_sata.c
> > @@ -982,6 +982,17 @@ static int fsl_ata_probe(struct udevice *dev)
> > failed_number++;
> > continue;
> > }
> > +
> > + ret = device_probe(bdev);
> > + if (ret < 0) {
> > + debug("Can't probe\n");
> > + ret = fsl_unbind_device(blk);
>
> Apart from this exception I guess
>
> > + if (ret)
> > + return ret;
> > +
> > + failed_number++;
> > + continue;
> > + }
> > }
> >
> > if (failed_number == nr_ports)
> > diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> > index 003222d47be6..09b735779ebf 100644
> > --- a/drivers/ata/sata_mv.c
> > +++ b/drivers/ata/sata_mv.c
> > @@ -1099,6 +1099,15 @@ static int sata_mv_probe(struct udevice *dev)
> > continue;
> > }
> >
> > + ret = device_probe(bdev);
> > + if (ret < 0) {
> > + debug("Can't probe\n");
> > + /* TODO: undo create */
> > +
> > + device_unbind(bdev);
> > + continue;
> > + }
> > +
> > /* If we got here, the current SATA port was probed
> > * successfully, so set the probe status to successful.
> > */
> > diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
> > index dda712f42cb2..295f7ca72303 100644
> > --- a/drivers/ata/sata_sil.c
> > +++ b/drivers/ata/sata_sil.c
> > @@ -864,6 +864,18 @@ static int sil_pci_probe(struct udevice *dev)
> > failed_number++;
> > continue;
> > }
> > +
> > + ret = device_probe(bdev);
> > + if (ret < 0) {
> > + debug("Can't probe\n");
> > + ret = sil_unbind_device(blk);
> > + device_unbind(bdev);
> > + if (ret)
> > + return ret;
> > +
> > + failed_number++;
> > + continue;
> > + }
> > }
> >
> > if (failed_number == sata_info.maxport)
> > --
> > 2.33.0
> >
Re: [PATCH v3 00/29] arm: dts: ls1028a: sync device tree with linux
On Thu, Sep 02, 2021 at 06:45:29PM +0200, Michael Walle wrote: > This series sync the device tree of the LS1028A SoC with the linux one. > To ease future debugging and reviewing, we first clean up the existing one, > removing bogus nodes, moving all CCSR related nodes in /soc and update the > drivers to accept the offical compatible strings. > > This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the > LS1028A-RDB and -QDS. It would be nice if someone could actually test it on > such a board. > > I didn't sync the device trees for the NXP boards because u-boot related > things aren't split into its own -u-boot.dtsi file. So I'll leave that task > to NXP :) > > The following patch is a prerequisite for this series: > > https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/ > > changes since v2: > - move the device tree nodes piece by piece and sort them to ease >reviewing > - fix PCI driver (bindings) > - fix SATA driver (bindings) > - fix USB driver (bindings) > - split most changes which are caused by the sync of the linux >device tree to own patches, eg. pcie io window, spi chip selects > > The final diff for the sync is much nicer now ;) > > changes since v1: > - remove u-boot,dm-pre-reloc from rdb and qds boards > - fix enetc0 and enetc2 labels These patches no longer apply, can you please resend?
Re: [PATCH] sunxi: Add support for FriendlyARM NanoPi R1S H5
On Sun, 3 Oct 2021 21:16:54 +0800
Chukun Pan wrote:
> This adds support for the NanoPi R1S H5 board.
>
> Allwinner H5 SoC
> 512MB DDR3 RAM
> 10/100/1000M Ethernet x 2
> RTL8189ETV WiFi 802.11b/g/n
> USB 2.0 host port (A)
> MicroSD Slot
> Reset button
> Serial Debug Port
> WAN - LAN - SYS LED
>
> The dts file is taken from Linux 5.14 tag, and includes the
> change to the eeprom node [1], which it's not yet merged.
Please don't include not-yet-merged parts in here. Make a verbatim copy
of the version in Linus' tree. I can fix this up while merging, if you
don't mind.
The change shouldn't affect U-Boot itself anyway, IIUC, but out of
curiosity: who is reading the MAC address out of the EEPROM, and how
does it land in the kernel (if it lands there)?
One more thing below:
>
> [1] https://lore.kernel.org/lkml/20211001145036.18129-1-amad...@jmu.edu.cn
>
> Signed-off-by: Chukun Pan
> ---
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 196 +++
> board/sunxi/MAINTAINERS | 5 +
> configs/nanopi_r1s_h5_defconfig | 13 ++
> 4 files changed, 215 insertions(+)
> create mode 100644 arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts
> create mode 100644 configs/nanopi_r1s_h5_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9e44817a40..e278480c1c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -632,6 +632,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
> sun50i-h5-libretech-all-h5-cc.dtb \
> sun50i-h5-nanopi-neo2.dtb \
> sun50i-h5-nanopi-neo-plus2.dtb \
> + sun50i-h5-nanopi-r1s-h5.dtb \
> sun50i-h5-orangepi-zero-plus.dtb \
> sun50i-h5-orangepi-pc2.dtb \
> sun50i-h5-orangepi-prime.dtb \
> diff --git a/arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts
> b/arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts
> new file mode 100644
> index 00..4f01c17c49
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2021 Chukun Pan
> + *
> + * Based on sun50i-h5-nanopi-neo-plus2.dts, which is:
> + * Copyright (C) 2017 Antony Antony
> + * Copyright (C) 2016 ARM Ltd.
> + */
> +
> +/dts-v1/;
> +#include "sun50i-h5.dtsi"
> +#include "sun50i-h5-cpu-opp.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "FriendlyARM NanoPi R1S H5";
> + compatible = "friendlyarm,nanopi-r1s-h5", "allwinner,sun50i-h5";
> +
> + aliases {
> + ethernet0 = &emac;
> + ethernet1 = &rtl8189etv;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_LAN;
> + color = ;
> + gpios = <&pio 0 9 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + led-2 {
> + function = LED_FUNCTION_WAN;
> + color = ;
> + gpios = <&pio 6 11 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + r-gpio-keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + reg_gmac_3v3: gmac-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "gmac-3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + startup-delay-us = <10>;
> + enable-active-high;
> + gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_usb0_vbus: usb0-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb0-vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + enable-active-high;
> + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
> + status = "okay";
> + };
> +
> + vdd_cpux: gpio-regulator {
> + compatible = "regulator-gpio";
> + regulator-name = "vdd-cpux";
> + regulator-type = "voltage";
> + regulator-boot-on;
> + regulator-always-on;
> +
Re: [PATCH] sun7i: Add defconfig and dts for Vivax TPC-9150 v3
On Sat, 2 Oct 2021 23:32:34 +0200
Nikola Pavlica wrote:
Hi Nikola,
> This patch uses the (almost) the same settings as those found in the
> original Android firmware. As such, it gurantees good compatibility.
>
> V2: Small fixes/changes to the config
>
> V3: Checkpatch fixes
Please try to fix those before hitting Send ;-) and please note patch
versions within the brackets ([PATCH v3]).
>
> Signed-off-by: Nikola Pavlica
> ---
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/sun7i-a20-vivax-tpc9150.dts | 259 +++
So the .dts file would need to go through a Linux review first. Please
send it there, and we will pick it up once it has been merged.
Cheers,
Andre
> board/sunxi/MAINTAINERS | 5 +
> configs/Vivax_TPC9150_defconfig | 13 ++
> 4 files changed, 278 insertions(+)
> create mode 100644 arch/arm/dts/sun7i-a20-vivax-tpc9150.dts
> create mode 100644 configs/Vivax_TPC9150_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fc16a57e60..d8e2248272 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -568,6 +568,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-pcduino3.dtb \
> sun7i-a20-pcduino3-nano.dtb \
> sun7i-a20-primo73.dtb \
> + sun7i-a20-vivax-tpc9150.dtb \
> sun7i-a20-wexler-tab7200.dtb \
> sun7i-a20-wits-pro-a20-dkt.dtb \
> sun7i-a20-yones-toptech-bd1078.dtb
> diff --git a/arch/arm/dts/sun7i-a20-vivax-tpc9150.dts
> b/arch/arm/dts/sun7i-a20-vivax-tpc9150.dts
> new file mode 100644
> index 00..78867c2fe0
> --- /dev/null
> +++ b/arch/arm/dts/sun7i-a20-vivax-tpc9150.dts
> @@ -0,0 +1,259 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2021 Nikola Pavlica
> + *
> + * DTS file for the Vivax TPC-9150 tablet
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Vivax TPC-9150 tablet";
> + compatible = "vivax,tpc-9150", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 1 2 4 6 8 11 14 18
> + 23 30 38 48 61 78 100>;
> + default-brightness-level = <16>;
> + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + power-supply = <®_vcc3v3>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + axp209: pmic@34 {
> + reg = <0x34>;
> + interrupt-parent = <&nmi_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&i2c1 {
> + status = "okay";
> +
> + // you need to manually probe this sensor, the kernel fails to do it on
> its own
> + stk8312@3d {
> + compatible = "STK8312", "stk8312";
> + reg = <0x3d>;
> + interrupt-parent = <&pio>;
> + interrupts = <7 0 IRQ_TYPE_EDGE_RISING>; /* PH0 / EINT0 */
> + };
> +};
> +
> +&i2c2 {
> + status = "okay";
> +
> + ft5x: touchscreen@38 {
> + compatible = "edt,edt-ft5406";
> + reg = <0x38>;
> + interrupt-parent = <&pio>;
> + interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; /* PH21 */
> +
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> +
> + bias-pull-up;
> + };
> +};
> +
> +&i2c3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +®_usb0_vbus {
> + status = "okay";
> +};
> +
> +®_usb1_vbus {
> + status = "okay";
> + gpio = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
> +};
> +
> +®_usb2_vbus {
> + status = "okay";
> + gpio = <&pio 7 3 GPIO_ACTIVE_HIGH>; /* PH3 */
> +};
> +
> +&usb_otg {
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /*
> PH4 */
> + usb0_vbus_power-supply = <&usb_power_supply>;
> + usb0_vbus-supply = <®_usb0_vbus>;
Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
Hi Takahiro, On Sun, 3 Oct 2021 at 21:44, AKASHI Takahiro wrote: > > # Resending the RFC as some of patches were deplicately submitted. > # See also > https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/dm_disk > > The purpose of this RPC is to reignite the discussion about how UEFI > subystem would best be integrated into U-Boot device model. > In the past, I poposed a couple of patch series, the latest one[1], > while Heinrich revealed his idea[2], and the approach taken here is > something between them, with a focus on block device handlings. > > # The code is a PoC and not well tested yet. [..] I expect to be able to dig into this at the end of the week. Regards, Simon Regards, Simon
RE: [PATCH v2 1/2] pinctrl: single: Parse gpio details from dt
> -Original Message- > From: Roman Bacik > Sent: Friday, October 1, 2021 3:40 PM > To: U-Boot Mailing List > Cc: Bharat Gooty ; Rayagonda Kokatanur > ; Roman Bacik > ; Dario Binacchi ; > Pratyush Yadav ; Simon Glass ; > Vignesh Raghavendra > Subject: [PATCH v2 1/2] pinctrl: single: Parse gpio details from dt > > From: Bharat Gooty > > Parse different gpio properties from dt as part of probe > function. This detail is required to enable pinctrl pad > later when gpio lines are requested. > > Signed-off-by: Rayagonda Kokatanur > > Signed-off-by: Bharat Gooty > Acked-by: Rayagonda Kokatanur > Signed-off-by: Roman Bacik > --- > > - modified comment before struct single_fpiofunc_range > - add pinctrl-single binding from Linux > - return error from single-probe() > - there is no test to be updated I will add tests to dm_test_pinctrl_single() in test/dm/pinmux.c and add a test node to arch/sandbox/dts/test.dts in version 3. > > .../pinctrl/pinctrl-single.txt| 255 ++ > drivers/pinctrl/pinctrl-single.c | 56 > 2 files changed, 311 insertions(+) > create mode 100644 doc/device-tree-bindings/pinctrl/pinctrl-single.txt > > diff --git a/doc/device-tree-bindings/pinctrl/pinctrl-single.txt b/doc/device- > tree-bindings/pinctrl/pinctrl-single.txt > new file mode 100644 > index ..e705acd3612c > --- /dev/null > +++ b/doc/device-tree-bindings/pinctrl/pinctrl-single.txt > @@ -0,0 +1,255 @@ > +One-register-per-pin type device tree based pinctrl driver > + > +Required properties: > +- compatible : "pinctrl-single" or "pinconf-single". > + "pinctrl-single" means that pinconf isn't supported. > + "pinconf-single" means that generic pinconf is supported. > + > +- reg : offset and length of the register set for the mux registers > + > +- #pinctrl-cells : number of cells in addition to the index, set to 1 > + for pinctrl-single,pins and 2 for pinctrl-single,bits > + > +- pinctrl-single,register-width : pinmux register access width in bits > + > +- pinctrl-single,function-mask : mask of allowed pinmux function bits > + in the pinmux register > + > +Optional properties: > +- pinctrl-single,function-off : function off mode for disabled state if > + available and same for all registers; if not specified, disabling of > + pin functions is ignored > + > +- pinctrl-single,bit-per-mux : boolean to indicate that one register controls > + more than one pin, for which "pinctrl-single,function-mask" property > specifies > + position mask of pin. > + > +- pinctrl-single,drive-strength : array of value that are used to configure > + drive strength in the pinmux register. They're value of drive strength > + current and drive strength mask. > + > + /* drive strength current, mask */ > + pinctrl-single,power-source = <0x30 0xf0>; > + > +- pinctrl-single,bias-pullup : array of value that are used to configure the > + input bias pullup in the pinmux register. > + > + /* input, enabled pullup bits, disabled pullup bits, mask */ > + pinctrl-single,bias-pullup = <0 1 0 1>; > + > +- pinctrl-single,bias-pulldown : array of value that are used to configure the > + input bias pulldown in the pinmux register. > + > + /* input, enabled pulldown bits, disabled pulldown bits, mask > */ > + pinctrl-single,bias-pulldown = <2 2 0 2>; > + > + * Two bits to control input bias pullup and pulldown: User should use > +pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means > +pullup, and the other one bit means pulldown. > + * Three bits to control input bias enable, pullup and pulldown. User should > +use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias > +enable bit should be included in pullup or pulldown bits. > + * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no > property as > +pinctrl-single,bias-disable. Because pinctrl single driver could implement > +it by calling pulldown, pullup disabled. > + > +- pinctrl-single,input-schmitt : array of value that are used to configure > + input schmitt in the pinmux register. In some silicons, there're two input > + schmitt value (rising-edge & falling-edge) in the pinmux register. > + > + /* input schmitt value, mask */ > + pinctrl-single,input-schmitt = <0x30 0x70>; > + > +- pinctrl-single,input-schmitt-enable : array of value that are used to > + configure input schmitt enable or disable in the pinmux register. > + > + /* input, enable bits, disable bits, mask */ > + pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>; > + > +- pinctrl-single,low-power-mode : array of value that are used to configure > + low power mode of this pin. For some silicons, the low power mode will > + control the output of the pin when the pad including the pin enter low > + power mode. > + /* low power mode value, mask */ > +
Re: [PATCH] sunxi: h3: enable clock support for r_pio gpios
On Mon, 26 Jul 2021 18:19:48 +0200 (CEST)
Manuel Dipolt wrote:
Hi Manuel,
> This patch enables clock for the r_pio gpios for the h3
Thanks for the patch, but can you say what this is needed for or what
it fixes?
Also this patch looks mangled, the leading spaces in the diff context
are gone, and tabs were converted to a single space - which makes this
impossible to apply.
Can you fix your settting, or find a better email client (git
send-email, for instance)?
Cheers,
Andre
> Signed-off-by: Manuel Dipolt
> ---
> drivers/clk/sunxi/Makefile | 1 +
> drivers/clk/sunxi/clk_h3-r.c | 51
> drivers/gpio/sunxi_gpio.c | 9 +++
> 3 files changed, 61 insertions(+)
> create mode 100644 drivers/clk/sunxi/clk_h3-r.c
>
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 36fb2aeb56..e93fe3c2f3 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -15,5 +15,6 @@ obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
> obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
> obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
> obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
> +obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3-r.o
> obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
> obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
> diff --git a/drivers/clk/sunxi/clk_h3-r.c b/drivers/clk/sunxi/clk_h3-r.c
> new file mode 100644
> index 00..a314e37b87
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk_h3-r.c
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2021 RobArt GmbH
> + * Author: Manuel Dipolt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct ccu_clk_gate h3_r_gates[] = {
> + [CLK_APB0_PIO] = GATE(0x28, BIT(0)),
> +};
> +
> +static struct ccu_reset h3_r_resets[] = {
> + [RST_APB0_IR] = RESET(0x0b0, BIT(2)),
> + [RST_APB0_TIMER] = RESET(0x0b0, BIT(3)),
> + [RST_APB0_UART] = RESET(0x0b0, BIT(4)),
> + [RST_APB0_I2C] = RESET(0x0b0, BIT(6)),
> +};
> +
> +static const struct ccu_desc h3_r_ccu_desc = {
> + .gates = h3_r_gates,
> + .resets = h3_r_resets,
> +};
> +
> +static int h3_r_clk_bind(struct udevice *dev)
> +{
> + return sunxi_reset_bind(dev, ARRAY_SIZE(h3_r_resets));
> +}
> +
> +static const struct udevice_id h3_r_ccu_ids[] = {
> + { .compatible = "allwinner,sun8i-h3-r-ccu",
> + .data = (ulong)&h3_r_ccu_desc },
> + { }
> +};
> +
> +U_BOOT_DRIVER(clk_sun8i_h3_r) = {
> + .name = "sun8i_h3-r_ccu",
> + .id = UCLASS_CLK,
> + .of_match = h3_r_ccu_ids,
> + .priv_auto_alloc_size = sizeof(struct ccu_priv),
> + .ops = &sunxi_clk_ops,
> + .probe = sunxi_clk_probe,
> + .bind = h3_r_clk_bind,
> +};
> +
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index cbed8d42b7..b505be4065 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -262,6 +263,14 @@ static int gpio_sunxi_probe(struct udevice *dev)
> {
> struct sunxi_gpio_platdata *plat = dev_get_platdata(dev);
> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct clk gate_clk;
> + int ret;
> +
> + ret = clk_get_by_name(dev, "apb", &gate_clk);
> +
> + if (!ret)
> + clk_enable(&gate_clk);
> +
>
> /* Tell the uclass how many GPIOs we have */
> if (plat) {
Re: FIT image: load secure FPGA
On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
Hello,
We are enabling secure boot on Zynqmp with SPL.
The issue however is that during secure boot, the bootrom not only
validates the first loader (SPL and PMUFW combo) but it will also
expect a signed bitstream during load(FPGA).
Since currently the SPL load of an FPGA image from FIT does not
support loading images for authentication (fpga_loads), I'd like to
discuss how to best implement such support.
What do you mean by "loading images for authentication" ?
A pretty standard file.its description of the FPGA loadable looks like
this:
fpga {
description = "FPGA binary";
data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
type = "fpga";
arch = "${UBOOT_ARCH}";
compression = "none";
load = <${fpgaloadaddr}>;
hash-1 {
algo = "${FIT_HASH_ALG}";
};
};
We could extend imagetool.h struct image_tool_params to add more
params or perhpas just define different 'types' of fpga?
Check "4) '/images' node"
in doc/uImage.FIT/source_file_format.txt
The intent is to give either:
* loadaddr="$(addr)" : copy image to $(addr), Done
* compatible="": Use this driver to upload the FPGA
It seems to me like the right way to go is to make a new compatible=""
FPGA loader is for fpga_load():
fpga {
description = "FPGA binary";
data = /incbin/("${YOCTO_BS_PATH}");
type = "fpga";
compression = "none";
compatible = "zynqmp-fancy-fpga",
hash-1 {
algo = "${FIT_HASHISH}";
};
};
Something like:
"fpga"
"fpga-auth" : authenticated
"fpga-enc" : encrypted
"fpga-sec" : encrypted and authenticated
Can these properties be inferred from the FPGA image? If not, they could
be required when using a new fpga loader. I don't think they should be
added to "fpga-legacy".
Alex
Then it would be a matter of modifying
https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
any thoughts?
TIA
Jorge
FIT image: load secure FPGA
Hello,
We are enabling secure boot on Zynqmp with SPL.
The issue however is that during secure boot, the bootrom not only
validates the first loader (SPL and PMUFW combo) but it will also
expect a signed bitstream during load(FPGA).
Since currently the SPL load of an FPGA image from FIT does not
support loading images for authentication (fpga_loads), I'd like to
discuss how to best implement such support.
A pretty standard file.its description of the FPGA loadable looks like
this:
fpga {
description = "FPGA binary";
data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
type = "fpga";
arch = "${UBOOT_ARCH}";
compression = "none";
load = <${fpgaloadaddr}>;
hash-1 {
algo = "${FIT_HASH_ALG}";
};
};
We could extend imagetool.h struct image_tool_params to add more
params or perhpas just define different 'types' of fpga?
Something like:
"fpga"
"fpga-auth" : authenticated
"fpga-enc" : encrypted
"fpga-sec" : encrypted and authenticated
Then it would be a matter of modifying
https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
any thoughts?
TIA
Jorge
Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
On Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote: > U-Boot makes use of the devicetree for its driver model. Devices are bound > based on the hardware description in the devicetree. > > Since U-Boot is not an operating system, it has no command line or user > space to provide configuration and policy information. This must be made > available in some other way. > > Therefore U-Boot uses devicetree for configuration and run-time control > and has done for approximately 9 years. This works extremely well in the > project and is very flexible. However the bindings have never been > incorporated in the devicetree bindings in the Linux tree. This could be > a good time to start this work as we try to create standard bindings for > communicating between firmware components. > > Add an initial binding for this node, covering just the config node, which > is the main requirement. It is similar in concept to the chosen node, but > used for passing information between firmware components, instead of from > firmware to operating system. > > Signed-off-by: Simon Glass > --- > Please be kind in your review. Some words about why this is needed are > included in the description in config.yaml file. > > The last attempt to add just one property needed by U-Boot went into the > weeds 6 years ago, with what I see as confusion about the role of the > chosen node in devicetree[1]. > > I am trying again in the hope of reaching resolution rather than just > going around in circles with the 'devicetree is a hardware description' > argument :-) > > Quoting from the introduction to latest devicetree spec[2]: > > >>> > To initialize and boot a computer system, various software components > interact. Firmware might perform low-level initialization of the system > hardware before passing control to software such as an operating system, > bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, > load and transfer control to operating systems. Standard, consistent > interfaces and conventions facilitate the interactions between these > software components. In this document the term boot program is used to > generically refer to a software component that initializes the system > state and executes another software component referred to as a client > program. > <<< > > This clearly envisages multiple software components in the firmware > domain and in fact that is the case today. They need some way to > communicate configuration data such as memory setup, runtime-feature > selection and developer conveniences. Devicetree seems ideal, at least for > components where the performance / memory requirements of devicetree are > affordable. > > I hope that the Linux community (which owns the devicetree bindings) finds > this initiative valuable and acceptable. Owns? I'm having a sale and can make you a good offer. Buy 1 binding, get 2000 free. :) > > [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html > [2] > https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 > > .../devicetree/bindings/u-boot/config.yaml| 137 ++ > 1 file changed, 137 insertions(+) > create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml Might as well put this into dt-schema rather than the kernel. But might get more review here first. > diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml > b/Documentation/devicetree/bindings/u-boot/config.yaml > new file mode 100644 > index 00..336577a17fdf5a > --- /dev/null > +++ b/Documentation/devicetree/bindings/u-boot/config.yaml > @@ -0,0 +1,137 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/u-boot/config.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: U-Boot configuration node > + > +maintainers: > + - Simon Glass > + > +description: | > + The config node does not represent a real device, but serves as a place > + for passing data between firmware elements, like memory maps. Data in the > + config node does not represent the hardware. It is ignored by operating > + systems. > + > + Purpose of config node > + -- > + > + A common problem with firmware is that many builds are needed to deal with > the > + slight variations between different, related models. For example, one model > + may have a TPM and another may not. Devicetree provides an excellent > solution > + to this problem, in that the devicetree to actually use on a platform can > be > + injected in the factory based on which model is being manufactured at the > time. > + > + A related problem causing build proliferation is dealing with the > differences > + between development firmware, developer-friendly firmware (e.g. with all > + security features present but with the ability to access the command line), > + test firmware (which runs tests used in the factory), final production > + firmw
Re: [PATCH 1/2] docs: dt: Fix a few grammar nits in the binding/schema docs
On Sun, 03 Oct 2021 12:50:06 -0600, Simon Glass wrote: > Add missing hyphens and reword one sentence for clarity. > > Signed-off-by: Simon Glass > --- > > .../devicetree/bindings/example-schema.yaml | 14 - > .../devicetree/bindings/writing-bindings.rst | 2 +- > .../devicetree/bindings/writing-schema.rst| 29 ++- > 3 files changed, 23 insertions(+), 22 deletions(-) > Applied, thanks!
Re: [resent RFC 14/22] efi_loader: disk: a helper function to create efi_disk objects from udevice
On Mon, Oct 04, 2021 at 12:44:22PM +0900, AKASHI Takahiro wrote:
> Add efi_disk_create() function.
>
> Any UEFI handle created by efi_disk_create() can be treated as a efi_disk
> object, the udevice is either a UCLASS_BLK (a whole raw disk) or
> UCLASS_PARTITION (a disk partition).
>
> So this function is expected to be called every time such an udevice
> is detected and activated through a device model's "probe" interface.
>
> Signed-off-by: AKASHI Takahiro
> ---
> include/efi_loader.h | 2 +
> lib/efi_loader/efi_disk.c | 92 +++
> 2 files changed, 94 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c440962fe522..751fde7fb153 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -517,6 +517,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t
> debug_disposition,
> void efi_carve_out_dt_rsv(void *fdt);
> /* Called by bootefi to make console interface available */
> efi_status_t efi_console_register(void);
> +/* Called when a block devices has been probed */
> +int efi_disk_create(struct udevice *dev);
> /* Called by bootefi to make all disk storage accessible as EFI objects */
> efi_status_t efi_disk_register(void);
> /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index cd5528046251..3fae40e034fb 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -484,6 +485,7 @@ error:
> return ret;
> }
>
> +#ifndef CONFIG_BLK
> /**
> * efi_disk_create_partitions() - create handles and protocols for partitions
> *
> @@ -531,6 +533,96 @@ int efi_disk_create_partitions(efi_handle_t parent,
> struct blk_desc *desc,
>
> return disks;
> }
> +#endif /* CONFIG_BLK */
> +
> +/*
> + * Create a handle for a whole raw disk
> + *
> + * @dev uclass device
> + * @return 0 on success, -1 otherwise
> + */
> +static int efi_disk_create_raw(struct udevice *dev)
> +{
> + struct efi_disk_obj *disk;
> + struct blk_desc *desc;
> + const char *if_typename;
> + int diskid;
> + efi_status_t ret;
> +
> + desc = dev_get_uclass_plat(dev);
> + if_typename = blk_get_if_type_name(desc->if_type);
> + diskid = desc->devnum;
> +
> + ret = efi_disk_add_dev(NULL, NULL, if_typename, desc,
> +diskid, NULL, 0, &disk);
> + if (ret != EFI_SUCCESS) {
> + log_err("Adding disk %s%d failed\n", if_typename, diskid);
> + return -1;
> + }
> + disk->dev = dev;
> + dev->efi_obj = &disk->header;
> +
> + return 0;
> +}
> +
> +/*
> + * Create a handle for a disk partition
> + *
> + * @dev uclass device
> + * @return 0 on success, -1 otherwise
> + */
> +static int efi_disk_create_part(struct udevice *dev)
> +{
> + efi_handle_t parent;
> + struct blk_desc *desc;
> + const char *if_typename;
> + struct disk_part *part_data;
> + struct disk_partition *info;
> + unsigned int part;
> + int diskid;
> + struct efi_device_path *dp = NULL;
> + struct efi_disk_obj *disk;
> + efi_status_t ret;
> +
> + parent = dev->parent->efi_obj;
> + desc = dev_get_uclass_plat(dev->parent);
> + if_typename = blk_get_if_type_name(desc->if_type);
> + diskid = desc->devnum;
> +
> + part_data = dev_get_uclass_plat(dev);
> + part = part_data->partnum;
> + info = &part_data->gpt_part_info;
> +
> + /* TODO: should not use desc? */
> + dp = efi_dp_from_part(desc, 0);
> +
> + ret = efi_disk_add_dev(parent, dp, if_typename, desc, diskid,
> +info, part, &disk);
> + if (ret != EFI_SUCCESS) {
> + log_err("Adding partition %s%d:%x failed\n",
> + if_typename, diskid, part);
> + return -1;
> + }
> + disk->dev = dev;
> + dev->efi_obj = &disk->header;
> +
> + return 0;
> +}
Can't we add a 'bool part' on this one and have a single function?
> +
> +int efi_disk_create(struct udevice *dev)
> +{
> + enum uclass_id id;
> +
> + id = device_get_uclass_id(dev);
> +
> + if (id == UCLASS_BLK)
> + return efi_disk_create_raw(dev);
> +
> + if (id == UCLASS_PARTITION)
> + return efi_disk_create_part(dev);
> +
> + return -1;
> +}
>
> /**
> * efi_disk_register() - register block devices
> --
> 2.33.0
>
Regards
/Ilias
Re: [resent RFC 06/22] sata: call device_probe() after scanning
On Mon, Oct 04, 2021 at 12:44:14PM +0900, AKASHI Takahiro wrote:
> Every time a sata bus/port is scanned and a new device is detected,
> we want to call device_probe() as it will give us a chance to run additional
> post-processings for some purposes.
>
> In particular, support for creating partitions on a device will be added.
>
> Signed-off-by: AKASHI Takahiro
> ---
> drivers/ata/dwc_ahsata.c | 10 ++
> drivers/ata/fsl_sata.c | 11 +++
> drivers/ata/sata_mv.c| 9 +
> drivers/ata/sata_sil.c | 12
> 4 files changed, 42 insertions(+)
>
> diff --git a/drivers/ata/dwc_ahsata.c b/drivers/ata/dwc_ahsata.c
> index 6d42548087b3..6a51c70d1170 100644
> --- a/drivers/ata/dwc_ahsata.c
> +++ b/drivers/ata/dwc_ahsata.c
> @@ -1026,6 +1026,16 @@ int dwc_ahsata_scan(struct udevice *dev)
> return ret;
> }
>
> + ret = device_probe(bdev);
> + if (ret < 0) {
> + debug("Can't probe\n");
> + /* TODO: undo create */
> +
> + device_unbind(bdev);
> +
> + return ret;
> + }
> +
Patches 2-6 seem to do the same thing for different subsystems. I think
creating a function for that would make it easier.
> return 0;
> }
>
> diff --git a/drivers/ata/fsl_sata.c b/drivers/ata/fsl_sata.c
> index e44db0a37458..346e9298b4c5 100644
> --- a/drivers/ata/fsl_sata.c
> +++ b/drivers/ata/fsl_sata.c
> @@ -982,6 +982,17 @@ static int fsl_ata_probe(struct udevice *dev)
> failed_number++;
> continue;
> }
> +
> + ret = device_probe(bdev);
> + if (ret < 0) {
> + debug("Can't probe\n");
> + ret = fsl_unbind_device(blk);
Apart from this exception I guess
> + if (ret)
> + return ret;
> +
> + failed_number++;
> + continue;
> + }
> }
>
> if (failed_number == nr_ports)
> diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> index 003222d47be6..09b735779ebf 100644
> --- a/drivers/ata/sata_mv.c
> +++ b/drivers/ata/sata_mv.c
> @@ -1099,6 +1099,15 @@ static int sata_mv_probe(struct udevice *dev)
> continue;
> }
>
> + ret = device_probe(bdev);
> + if (ret < 0) {
> + debug("Can't probe\n");
> + /* TODO: undo create */
> +
> + device_unbind(bdev);
> + continue;
> + }
> +
> /* If we got here, the current SATA port was probed
>* successfully, so set the probe status to successful.
>*/
> diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
> index dda712f42cb2..295f7ca72303 100644
> --- a/drivers/ata/sata_sil.c
> +++ b/drivers/ata/sata_sil.c
> @@ -864,6 +864,18 @@ static int sil_pci_probe(struct udevice *dev)
> failed_number++;
> continue;
> }
> +
> + ret = device_probe(bdev);
> + if (ret < 0) {
> + debug("Can't probe\n");
> + ret = sil_unbind_device(blk);
> + device_unbind(bdev);
> + if (ret)
> + return ret;
> +
> + failed_number++;
> + continue;
> + }
> }
>
> if (failed_number == sata_info.maxport)
> --
> 2.33.0
>
Re: [resent RFC 08/22] dm: blk: add UCLASS_PARTITION
Hi Akashi-san,
>
[...]
> +int blk_create_partitions(struct udevice *parent)
> +{
> + int part, count;
> + struct blk_desc *desc = dev_get_uclass_plat(parent);
> + struct disk_partition info;
> + struct disk_part *part_data;
> + char devname[32];
> + struct udevice *dev;
> + int ret;
> +
> + if (!CONFIG_IS_ENABLED(PARTITIONS) ||
> + !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
> + return 0;
Would it make more sense to return an error here?
> +
> + /* Add devices for each partition */
> + for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> + if (part_get_info(desc, part, &info))
> + continue;
> + snprintf(devname, sizeof(devname), "%s:%d", parent->name,
> + part);
> +
> + ret = device_bind_driver(parent, "blk_partition",
> + strdup(devname), &dev);
> + if (ret)
> + return ret;
> +
> + part_data = dev_get_uclass_plat(dev);
> + part_data->partnum = part;
> + part_data->gpt_part_info = info;
> + count++;
> +
> + device_probe(dev);
Probe can fail.
> + }
> + debug("%s: %d partitions found in %s\n", __func__, count, parent->name);
> +
> + return 0;
> +}
> +
> static int blk_post_probe(struct udevice *dev)
> {
> if (IS_ENABLED(CONFIG_PARTITIONS) &&
> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {
> .post_probe = blk_post_probe,
> .per_device_plat_auto = sizeof(struct blk_desc),
> };
[...]
Regards
/Ilias
Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Mon, Oct 04, 2021 at 04:47:53PM +0200, Heinrich Schuchardt wrote:
>
>
> >
[...]
> > My approach in this RFC:
> >
> > Due to functional differences in semantics, it would be difficult
> > to identify "udevice" structure as a handle in UEFI world. Instead, we will
> > have to somehow maintain a relationship between a udevice and a handle.
> >
> > 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions
> > Currently, the uclass for paritions is not a UCLASS_BLK.
> > It can be possible to define partitions as UCLASS_BLK
> > (with IF_TYPE_PARTION?), but
> > I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK)
> > is tightly coupled with 'struct blk_desc' data which is still used
> > as a "structure to a whole disk" in a lot of interfaces.
> > (I hope that you understand what it means.)
I think it makes more sense the way it's currently defined. I don;t see a
point in hiding partitions within UCLASS_BLK
> >
> > In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent:
> > For instance,
> > UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION
> > (IF_TYPE_SCSI)|
> >+- struct blk_desc +- struct disk_part
> > +- scsi_blk_ops +- blk_part_ops
> >
> > 1-2. create partition udevices in the context of device_probe()
> > part_init() is already called in blk_post_probe(). See the commit
> > d0851c893706 ("blk: Call part_init() in the post_probe() method").
> > Why not enumelate partitions as well in there.
> >
> > 2. add new block access interfaces, which takes "udevice" as a target
> > device,
> > in U-Boot and use those functions to implement efi_disk operations
> > (i.e. EFI_BLOCK_IO_PROTOCOL).
> >
> > 3-1. maintain a bi-directional link by adding
> > - a UEFI handle pointer in "struct udevice"
> > - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj")
>
> An EFI application can create handles with any combination of protocols,
> e.g. a handle with both the block IO protocol and the simple network
> protocol. This means that a udevice cannot be assigned to a handle
> created by an EFI application.
>
> When the EFI application calls ConnectController() for the handle,
> U-Boot can create child controllers. If U-Boot creates a udevice for
> such a child controller, it has to store the udevice pointer.
> lib/efi_driver/efi_block_device.c uses a private data section but you it
> could be preferable to use a field in struct efi_obj.
>
I agree with Heinrich here. Basically U-Boot has to be in charge of that.
Once ConnectController has been called U-Boot should create an 1:1 mapping
between udevice <-> handle and shouldn't be allowed to change that.
> >
> > 3-2. use device model's post_probe/pre_remove hook to synchronize the
> > lifetime
> > of efi_disk objects in UEFI world with the device model.
> >
> > 4. I have no answer to issue(4) and (5) yet.
>
> 4) A udevice shall only exist for the child controller handle created by
> U-Boot and not for the controller handle created by an EFI application.
>
> 5) The stop() method of the driver binding protocol has to take care of
> destroying the child controllers and the associated udevices.
>
> Best regards
>
> Heinrich
Thanks
/Ilias
[PATCH] ppc: mpc8xx: Drop -mstring from PLATFORM_CPPFLAGS
This has not been supported by toolchains for some time and has been putting out a warning. Drop this. Signed-off-by: Tom Rini --- arch/powerpc/cpu/mpc8xx/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc8xx/config.mk b/arch/powerpc/cpu/mpc8xx/config.mk index 00b7ed50a9d3..5a64665a6180 100644 --- a/arch/powerpc/cpu/mpc8xx/config.mk +++ b/arch/powerpc/cpu/mpc8xx/config.mk @@ -3,4 +3,4 @@ # (C) Copyright 2000-2010 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -PLATFORM_CPPFLAGS += -mstring -mcpu=860 -msoft-float +PLATFORM_CPPFLAGS += -mcpu=860 -msoft-float -- 2.17.1
Re: [ANN] U-Boot v2021.10 released
On Mon, Oct 04, 2021 at 11:11:08AM -0400, Tom Rini wrote: > Hey all, > > It is release day and here is v2021.10. With this release > we are now at the third of our 2 years past a number of DM migration > deadlines. We're now at the point where it's watchdog related > migrations that are past due. This is actually a small list of boards > and I think can be quickly resolved. At this point, between what has > been removed for this release and what's queued up already in -next, > we've made good progress on clearing out legacy platforms. > > What I would like to call attention to in general is the number of > CONFIG symbols that need to be migrated to Kconfig still. If you > maintain a board or SoC, please check for symbols specific to your area > of code that aren't migrated yet and see how to move them. The > tools/moveconfig.py tool can handle a lot of cases. If it's tricky > please reach out. > > In terms of a changelog, > git log --merges v2021.10-rc4..v2021.10-rc5 > contains what I've pulled since the last RC or: > git log --merges v2021.07..v2021.10 > for changes since the last full release. As always, more details in > pull requests (or the tags referenced by them) will result in more > details here. > > With this, the merge window is now open and I'll be merging in the next > branch shortly. v2022.01 is scheduled for release on Monday, January > 10th 2022 and the merge window closes on October 25th. Thanks all! I have pushed next in to master now. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "configs: stm32mp1: only support SD card after NOR in bootcmd_stm32mp"
On 10/4/21 6:34 PM, Patrick DELAUNAY wrote:
Hi,
Hi,
On 10/4/21 1:48 PM, Marek Vasut wrote:
This reverts commit d5d726d3cc47691ace3c68fa31147ad104aaf579,
which breaks boards which ship with multiple SD/eMMC sockets.
This stm32mp1.h config is not used only by the ST reference
boards, but all the other STM32MP1 based boards in U-Boot, so
changes to this stm32mp1.h cannot break the other boards.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
NOTE: I think we might need to split out the env for different
boards into different headers instead. Thoughts ?
---
include/configs/stm32mp1.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 973a4f1d4b8..a75ed693f57 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -120,7 +120,7 @@
* for serial/usb: execute the stm32prog command
* for mmc boot (eMMC, SD card), boot only on the same device
* for nand or spi-nand boot, boot with on ubifs partition on UBI
partition
- * for nor boot, use SD card = mmc0
+ * for nor boot, use the default order
*/
#define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
"echo \"Boot over ${boot_device}${boot_instance}!\";" \
@@ -133,8 +133,6 @@
"if test ${boot_device} = nand ||" \
" test ${boot_device} = spi-nand ;" \
"then env set boot_targets ubifs0; fi;" \
- "if test ${boot_device} = nor;" \
- "then env set boot_targets mmc0; fi;" \
"run distro_bootcmd;" \
"fi;\0"
Reviewed-by: Patrick Delaunay
Sorry to break your board, but I assumed the "stm32mp1.h" was only the
default ST configuration
No worries really. No, it isn't only for the ST evalboards, and I don't
know whether this is the right approach.
for ST boards and other boards need to be overridden it if it is not
align with their needs
as I don't know the expected boot sequence.
for example with:
CONFIG_BOOTCOMMAND="run bootcmd_dh_stm32mp"
with bootcmd_dh_stm32mp to be defined
but today this file is a mix between SOC configuration (generic) and ST
boards needs.
So I will merge your revert and I will push a other solution to only
support SD card
after NOR in bootcmd_stm32mp but only for STMicroelectronics boards
(because the revert now break the EV1 boot from NOR).
1) stm32mp1.h = common for SOC STMP15x (as today)
2) st_stm32mp1.h = ST boards configuration (override common)
Maybe the naming should be the other way around, so we have some sort of
namespacing, like this:
stm32mp1_common.h
... common stuff for all boards and SoM and all ...
stm32mp1_st_evalboard.h (or whatever you want to call it)
#include
#define custom ST env ...
stm32mp1_dh_dhsom.h
#include
#define custom DH env ...
That's what imx does , except for the namespacing, so the file names are
a mess. I think we can do better there. So anything related to stm32mp1
should have stm32mp1_* filename prefix, and then some vendor_ or board_
suffix.
Re: [PATCH v8 2/5] board: siemens: Add support for SIMATIC IOT2050 devices
On 04.10.21 18:02, Tom Rini wrote: > On Mon, Oct 04, 2021 at 05:54:46PM +0200, Jan Kiszka wrote: >> On 04.10.21 01:34, Tom Rini wrote: >>> On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote: >>> From: Jan Kiszka This adds support for the IOT2050 Basic and Advanced devices. The Basic used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS quad-core version. Both variants are booted via a Siemens-provided FSBL that runs on the R5 cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot SPL, ATF and TEE have to reside in SPI flash. Full integration into a bootable image can be found on https://github.com/siemens/meta-iot2050 Based on original board support by Le Jin, Gao Nian and Chao Zeng. Signed-off-by: Jan Kiszka >>> >>> Applied to u-boot/next, thanks! >>> >> >> Thanks for merging - it just does not boot anymore, no output after >> TF-A. Trying to understand the differences now, already ruled out >> arch/arm/dts/k3-am65* as source. > > Have you enabled debug uart? I found that quite helpful figuring out > what was wrong when updating the dts files, and the correct values for > that are in the dts files too. > We do, and it stays silent so far. Meanwhile I already updated the defconfig, in line with the changes to the similar am65x_evm* (CONFIG_SPL_SERIAL[_SUPPORT]...), but no break-through yet. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] Revert "configs: stm32mp1: only support SD card after NOR in bootcmd_stm32mp"
Hi,
On 10/4/21 1:48 PM, Marek Vasut wrote:
This reverts commit d5d726d3cc47691ace3c68fa31147ad104aaf579,
which breaks boards which ship with multiple SD/eMMC sockets.
This stm32mp1.h config is not used only by the ST reference
boards, but all the other STM32MP1 based boards in U-Boot, so
changes to this stm32mp1.h cannot break the other boards.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
NOTE: I think we might need to split out the env for different
boards into different headers instead. Thoughts ?
---
include/configs/stm32mp1.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 973a4f1d4b8..a75ed693f57 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -120,7 +120,7 @@
* for serial/usb: execute the stm32prog command
* for mmc boot (eMMC, SD card), boot only on the same device
* for nand or spi-nand boot, boot with on ubifs partition on UBI partition
- * for nor boot, use SD card = mmc0
+ * for nor boot, use the default order
*/
#define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
"echo \"Boot over ${boot_device}${boot_instance}!\";" \
@@ -133,8 +133,6 @@
"if test ${boot_device} = nand ||" \
" test ${boot_device} = spi-nand ;" \
"then env set boot_targets ubifs0; fi;" \
- "if test ${boot_device} = nor;" \
- "then env set boot_targets mmc0; fi;" \
"run distro_bootcmd;" \
"fi;\0"
Reviewed-by: Patrick Delaunay
Sorry to break your board, but I assumed the "stm32mp1.h" was only the
default ST configuration
for ST boards and other boards need to be overridden it if it is not
align with their needs
as I don't know the expected boot sequence.
for example with:
CONFIG_BOOTCOMMAND="run bootcmd_dh_stm32mp"
with bootcmd_dh_stm32mp to be defined
but today this file is a mix between SOC configuration (generic) and ST
boards needs.
So I will merge your revert and I will push a other solution to only
support SD card
after NOR in bootcmd_stm32mp but only for STMicroelectronics boards
(because the revert now break the EV1 boot from NOR).
1) stm32mp1.h = common for SOC STMP15x (as today)
2) st_stm32mp1.h = ST boards configuration (override common)
Thanks
Patrick
Re: [PATCH] video: move MXS to Kconfig
Hi Anatolij, On Mon, Oct 4, 2021 at 12:33 PM Anatolij Gustschin wrote: > > Move CONFIG_VIDEO_MXS from board headers to Kconfig > and drop it from obsolete cfb_console driver. > > Signed-off-by: Anatolij Gustschin > --- > I'm CCing board maintainers, please review/ack. Reviewed-by: Fabio Estevam Thanks
Re: [PATCH v8 2/5] board: siemens: Add support for SIMATIC IOT2050 devices
On Mon, Oct 04, 2021 at 05:54:46PM +0200, Jan Kiszka wrote: > On 04.10.21 01:34, Tom Rini wrote: > > On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote: > > > >> From: Jan Kiszka > >> > >> This adds support for the IOT2050 Basic and Advanced devices. The Basic > >> used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS > >> quad-core version. > >> > >> Both variants are booted via a Siemens-provided FSBL that runs on the R5 > >> cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot > >> SPL, ATF and TEE have to reside in SPI flash. > >> > >> Full integration into a bootable image can be found on > >> https://github.com/siemens/meta-iot2050 > >> > >> Based on original board support by Le Jin, Gao Nian and Chao Zeng. > >> > >> Signed-off-by: Jan Kiszka > > > > Applied to u-boot/next, thanks! > > > > Thanks for merging - it just does not boot anymore, no output after > TF-A. Trying to understand the differences now, already ruled out > arch/arm/dts/k3-am65* as source. Have you enabled debug uart? I found that quite helpful figuring out what was wrong when updating the dts files, and the correct values for that are in the dts files too. -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 2/5] board: siemens: Add support for SIMATIC IOT2050 devices
On 04.10.21 01:34, Tom Rini wrote: > On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote: > >> From: Jan Kiszka >> >> This adds support for the IOT2050 Basic and Advanced devices. The Basic >> used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS >> quad-core version. >> >> Both variants are booted via a Siemens-provided FSBL that runs on the R5 >> cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot >> SPL, ATF and TEE have to reside in SPI flash. >> >> Full integration into a bootable image can be found on >> https://github.com/siemens/meta-iot2050 >> >> Based on original board support by Le Jin, Gao Nian and Chao Zeng. >> >> Signed-off-by: Jan Kiszka > > Applied to u-boot/next, thanks! > Thanks for merging - it just does not boot anymore, no output after TF-A. Trying to understand the differences now, already ruled out arch/arm/dts/k3-am65* as source. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v5 3/5] env: Allow U-Boot scripts to be placed in a .env file
On Mon, Oct 04, 2021 at 09:28:43AM +0200, Rasmus Villemoes wrote: > On 02/10/2021 02.38, Simon Glass wrote: > > At present U-Boot environment variables, and thus scripts, are defined > > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text > > to this file and dealing with quoting and newlines is harder than it > > should be. It would be better if we could just type the script into a > > text file and have it included by U-Boot. > > Indeed, the pain of CONFIG_EXTRA_ENV_SETTINGS was part of the motivation > for introducing CONFIG_USE_DEFAULT_ENV_FILE. > > > Add a feature that brings in a .env file associated with the board > > config, if present. To use it, create a file in a board//env > > directory called .env (or common.env if you want the same > > environment for all boards). > > > > The environment variables should be of the form "var=value". Values can > > extend to multiple lines. See the README under 'Environment Variables:' > > for more information and an example. > > > > Comments are not permitted in the environment with this commit. > > Perhaps some remarks on how this compares/relates to > CONFIG_USE_DEFAULT_ENV_FILE and CONFIG_ENV_IMPORT_FDT would be in order? > In particular, the latter seems like it could already do the "amend the > environent per vendor/board" with appropriate settings in the > -u-boot.dtsi files? > > I don't think either of those currently support using CONFIG_ variables > in the definitions, but perhaps that could be fixed. > > I don't have anything against these patches as such, I'd just like to > understand precisely what they bring that cannot already be done with > existing mechanisms. So, the high level requirement is to move the environment out of the board.h file (or the nest of #includes that uses to cobble it together). That does mean that CONFIG_USE_DEFAULT_ENV_FILE at least would likely need some tweaking, but may also be just not as useful, if it's no longer such a pain to modify the default environment. -- Tom signature.asc Description: PGP signature
[PATCH] video: move MXS to Kconfig
Move CONFIG_VIDEO_MXS from board headers to Kconfig and drop it from obsolete cfb_console driver. Signed-off-by: Anatolij Gustschin --- I'm CCing board maintainers, please review/ack. configs/colibri-imx6ull_defconfig | 1 + configs/colibri_imx7_defconfig| 1 + configs/imxrt1050-evk_defconfig | 1 + configs/mx6ul_14x14_evk_defconfig | 1 + configs/mx6ul_9x9_evk_defconfig | 1 + configs/opos6uldev_defconfig | 1 + configs/pico-imx6ul_defconfig | 1 + configs/pico-imx7d_bl33_defconfig | 1 + configs/pico-imx7d_defconfig | 1 + drivers/video/Kconfig | 6 ++ drivers/video/cfb_console.c | 4 include/configs/colibri-imx6ull.h | 3 +-- include/configs/colibri_imx7.h| 3 +-- include/configs/imxrt1050-evk.h | 1 - include/configs/mx23evk.h | 2 +- include/configs/mx28evk.h | 2 +- include/configs/mx6sxsabresd.h| 3 +-- include/configs/mx6ul_14x14_evk.h | 1 - include/configs/mx7dsabresd.h | 3 +-- include/configs/mxs.h | 5 - include/configs/opos6uldev.h | 1 - include/configs/pico-imx6ul.h | 3 +-- include/configs/pico-imx7d.h | 1 - 23 files changed, 22 insertions(+), 25 deletions(-) diff --git a/configs/colibri-imx6ull_defconfig b/configs/colibri-imx6ull_defconfig index 739eea7c07..129b01f747 100644 --- a/configs/colibri-imx6ull_defconfig +++ b/configs/colibri-imx6ull_defconfig @@ -94,6 +94,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 39149167e0..4dccfe815c 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -90,6 +90,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/imxrt1050-evk_defconfig b/configs/imxrt1050-evk_defconfig index 6b302a7b82..3c7629c963 100644 --- a/configs/imxrt1050-evk_defconfig +++ b/configs/imxrt1050-evk_defconfig @@ -70,6 +70,7 @@ CONFIG_USB=y # CONFIG_SPL_DM_USB is not set CONFIG_USB_EHCI_HCD=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_BACKLIGHT_GPIO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y diff --git a/configs/mx6ul_14x14_evk_defconfig b/configs/mx6ul_14x14_evk_defconfig index d28b6f6e3c..50b7f98a60 100644 --- a/configs/mx6ul_14x14_evk_defconfig +++ b/configs/mx6ul_14x14_evk_defconfig @@ -89,6 +89,7 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/mx6ul_9x9_evk_defconfig b/configs/mx6ul_9x9_evk_defconfig index 1425724429..0ecb1eb72e 100644 --- a/configs/mx6ul_9x9_evk_defconfig +++ b/configs/mx6ul_9x9_evk_defconfig @@ -79,6 +79,7 @@ CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/opos6uldev_defconfig b/configs/opos6uldev_defconfig index 1e8d56e788..8e6f520fb1 100644 --- a/configs/opos6uldev_defconfig +++ b/configs/opos6uldev_defconfig @@ -102,6 +102,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP32 is not set CONFIG_SYS_WHITE_ON_BLACK=y diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig index f027c866f5..2f2e5f9494 100644 --- a/configs/pico-imx6ul_defconfig +++ b/configs/pico-imx6ul_defconfig @@ -77,5 +77,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/pico-imx7d_bl33_defconfig b/configs/pico-imx7d_bl33_defconfig index 4657d51e23..24dbdcdafb 100644 --- a/configs/pico-imx7d_bl33_defconfig +++ b/configs/pico-imx7d_bl33_defconfig @@ -72,6 +72,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/configs/pico-imx7d_defconfig b/configs/pico-imx7d_defconfig index c682948218..855c936f6e 100644 --- a/configs/pico-imx7d_defconfig +++ b/configs/pico-imx7d_defconfig @@ -76,6 +76,7 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_DM_VIDEO=y +CONFIG_VIDEO_MXS=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8b940d70eb..85a8635022 100644 --- a/drivers
[ANN] U-Boot v2021.10 released
Hey all, It is release day and here is v2021.10. With this release we are now at the third of our 2 years past a number of DM migration deadlines. We're now at the point where it's watchdog related migrations that are past due. This is actually a small list of boards and I think can be quickly resolved. At this point, between what has been removed for this release and what's queued up already in -next, we've made good progress on clearing out legacy platforms. What I would like to call attention to in general is the number of CONFIG symbols that need to be migrated to Kconfig still. If you maintain a board or SoC, please check for symbols specific to your area of code that aren't migrated yet and see how to move them. The tools/moveconfig.py tool can handle a lot of cases. If it's tricky please reach out. In terms of a changelog, git log --merges v2021.10-rc4..v2021.10-rc5 contains what I've pulled since the last RC or: git log --merges v2021.07..v2021.10 for changes since the last full release. As always, more details in pull requests (or the tags referenced by them) will result in more details here. With this, the merge window is now open and I'll be merging in the next branch shortly. v2022.01 is scheduled for release on Monday, January 10th 2022 and the merge window closes on October 25th. Thanks all! -- Tom signature.asc Description: PGP signature
[PATCH] video: remove not used mx3fb driver
i.MX31 support was removed, and the non dm-video driver
is obsolete and not used. Remove it.
Signed-off-by: Anatolij Gustschin
---
drivers/video/Makefile | 1 -
drivers/video/cfb_console.c | 7 -
drivers/video/mx3fb.c | 906
3 files changed, 914 deletions(-)
delete mode 100644 drivers/video/mx3fb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 7ae0ab2b35..95c1674edc 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -62,7 +62,6 @@ obj-$(CONFIG_VIDEO_MCDE_SIMPLE) += mcde_simple.o
obj-${CONFIG_VIDEO_MESON} += meson/
obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
obj-$(CONFIG_VIDEO_MVEBU) += mvebu_lcd.o
-obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
obj-$(CONFIG_VIDEO_MXS) += mxsfb.o videomodes.o
obj-$(CONFIG_VIDEO_NX) += nexell_display.o videomodes.o nexell/
obj-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 5e1ee061e8..18d3354950 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -81,13 +81,6 @@
#define VIDEO_FB_16BPP_WORD_SWAP
#endif
-/*
- * Defines for the i.MX31 driver (mx3fb.c)
- */
-#if defined(CONFIG_VIDEO_MX3) || defined(CONFIG_VIDEO_IPUV3)
-#define VIDEO_FB_16BPP_WORD_SWAP
-#endif
-
/*
* Include video_fb.h after definitions of VIDEO_HW_RECTFILL etc.
*/
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
deleted file mode 100644
index e6dd2b83c6..00
--- a/drivers/video/mx3fb.c
+++ /dev/null
@@ -1,906 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2009
- * Guennadi Liakhovetski, DENX Software Engineering,
- * Copyright (C) 2011
- * HALE electronic GmbH,
- */
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include "videomodes.h"
-
-/* this might need panel specific set-up as-well */
-#define IF_CONF0
-
-/* -- controller specific stuff -- */
-
-/* IPU DMA Controller channel definitions. */
-enum ipu_channel {
- IDMAC_IC_0 = 0, /* IC (encoding task) to memory */
- IDMAC_IC_1 = 1, /* IC (viewfinder task) to memory */
- IDMAC_ADC_0 = 1,
- IDMAC_IC_2 = 2,
- IDMAC_ADC_1 = 2,
- IDMAC_IC_3 = 3,
- IDMAC_IC_4 = 4,
- IDMAC_IC_5 = 5,
- IDMAC_IC_6 = 6,
- IDMAC_IC_7 = 7, /* IC (sensor data) to memory */
- IDMAC_IC_8 = 8,
- IDMAC_IC_9 = 9,
- IDMAC_IC_10 = 10,
- IDMAC_IC_11 = 11,
- IDMAC_IC_12 = 12,
- IDMAC_IC_13 = 13,
- IDMAC_SDC_0 = 14, /* Background synchronous display data */
- IDMAC_SDC_1 = 15, /* Foreground data (overlay) */
- IDMAC_SDC_2 = 16,
- IDMAC_SDC_3 = 17,
- IDMAC_ADC_2 = 18,
- IDMAC_ADC_3 = 19,
- IDMAC_ADC_4 = 20,
- IDMAC_ADC_5 = 21,
- IDMAC_ADC_6 = 22,
- IDMAC_ADC_7 = 23,
- IDMAC_PF_0 = 24,
- IDMAC_PF_1 = 25,
- IDMAC_PF_2 = 26,
- IDMAC_PF_3 = 27,
- IDMAC_PF_4 = 28,
- IDMAC_PF_5 = 29,
- IDMAC_PF_6 = 30,
- IDMAC_PF_7 = 31,
-};
-
-/* More formats can be copied from the Linux driver if needed */
-enum pixel_fmt {
- /* 2 bytes */
- IPU_PIX_FMT_RGB565,
- IPU_PIX_FMT_RGB666,
- IPU_PIX_FMT_BGR666,
- /* 3 bytes */
- IPU_PIX_FMT_RGB24,
-};
-
-struct pixel_fmt_cfg {
- u32 b0;
- u32 b1;
- u32 b2;
- u32 acc;
-};
-
-static struct pixel_fmt_cfg fmt_cfg[] = {
- [IPU_PIX_FMT_RGB24] = {
- 0x1600, 0x00E0, 0x0007, 3,
- },
- [IPU_PIX_FMT_RGB666] = {
- 0x0005000F, 0x000B000F, 0x0011000F, 1,
- },
- [IPU_PIX_FMT_BGR666] = {
- 0x0011000F, 0x000B000F, 0x0005000F, 1,
- },
- [IPU_PIX_FMT_RGB565] = {
- 0x0004003F, 0x000A000F, 0x000F003F, 1,
- }
-};
-
-enum ipu_panel {
- IPU_PANEL_SHARP_TFT,
- IPU_PANEL_TFT,
-};
-
-/* IPU Common registers */
-/* IPU_CONF and its bits already defined in imx-regs.h */
-#define IPU_CHA_BUF0_RDY (0x04 + IPU_BASE)
-#define IPU_CHA_BUF1_RDY (0x08 + IPU_BASE)
-#define IPU_CHA_DB_MODE_SEL(0x0C + IPU_BASE)
-#define IPU_CHA_CUR_BUF(0x10 + IPU_BASE)
-#define IPU_FS_PROC_FLOW (0x14 + IPU_BASE)
-#define IPU_FS_DISP_FLOW (0x18 + IPU_BASE)
-#define IPU_TASKS_STAT (0x1C + IPU_BASE)
-#define IPU_IMA_ADDR (0x20 + IPU_BASE)
-#define IPU_IMA_DATA (0x24 + IPU_BASE)
-#define IPU_INT_CTRL_1 (0x28 + IPU_BASE)
-#define IPU_INT_CTRL_2 (0x2C + IPU_BASE)
-#define IPU_INT_CTRL_3 (0x30 + IPU_BASE)
-#define IPU_INT_CTRL_4 (0x34 + IPU_BASE)
-#define IPU_INT_CTRL_5 (0x38 + IPU_BASE)
-#define IPU_INT_STAT_1 (0x3C + IPU_BASE)
-#define IPU_INT_STAT_2 (0x40 + IPU_BASE)
-#define IPU_INT_STAT_3 (0x44 + IPU_BASE)
-#define IPU_I
Re: [PATCH v2 00/11] stm32mp1: Support falcon mode with OP-TEE payloads
Hi Alexandru
On 9/8/21 1:59 AM, Alexandru Gagniuc wrote:
My goal when I started on this project a year ago was to get to linux
userspace within a second from power on. Oh, and it had to be secure!
Contrast that to the two minutes it took the STLinux demo to come up.
It was obvious that the accepted way of running an FSBL, then SSBL was
going to blow the time budget. There really wasn't a good solution,
and traditional falcon mode with "spl export" command was not secure.
I chose to use SPL with a FIT payload. We have to add certain logic to
SPL, as well as some FDT modifications that would be normally done in
u-boot. The boot flow is
SPL -> OP-TEE -> Linux
One of the major complaints of v1 was that we shouldn't be patching
the devicetree with optee nodes in SPL. Instead, we should let OP-TEE
add the required nodes. I tried it, found a huge boot time penalty,
and decided against it.
Another issue from v1 that I was unable to address is the MAC address.
It was suggested to use the "nvmem-cells" FDT property to tell linux
where in the OTP to read the MAC. Because of the way the linux BSEC
driver is written, this would only work with TF-A, but fails with SPL.
There is also the issue of how to make the optee/ library available to
SPL. Patrick has a couple of patches up regarding the issue, so I have
not touched it in this series.
Changes since v1:
- Move SYS_MMCSD_RAW_MODE_KERNEL_SECTOR to Kconfig instead of stm32mp1.h
- Create a new defconfig for STM32MP in falcon mode
- Rework board_fit_config_name_match() per Patrick's suggestions
- Use "u-boot,falcon-gpios" instead of "st,fastboot-gpios"
- Only update shadow registers in SPL for BSEC .probe()
Alexandru Gagniuc (11):
spl: Move SYS_MMCSD_RAW_MODE_KERNEL_SECTOR to Kconfig
=> OK
stm32mp1: Add support for baudrates higher than 115200
=> OK
stm32mp1: Add support for falcon mode boot from SD card
=> some remarks
board: stm32mp1: Implement board_fit_config_name_match() for SPL
=> OK
For the next commit of the serie
I am not a specialist of falcon mode but I think all the next commit
should be removed if the falcon mode is correctly managed
see the command "spl export" in doc/README.falcon
arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon:19:
=> the fixup is done one time and saved in U-Boot proper (first boot ?)
before to activate the Falcon mode
see also CONFIG_SYS_SPL_ARGS_ADDR usage in ls1043a
and in :
void board_init_r(gd_t *dummy1, ulong dummy2)
{
case IH_OS_LINUX:
debug("Jumping to Linux\n");
#ifdefined(CONFIG_SYS_SPL_ARGS_ADDR)
spl_fixup_fdt((void*)CONFIG_SYS_SPL_ARGS_ADDR);
#endif
=>jump_to_image_linux use the address spl_image->arg =
CONFIG_SYS_SPL_ARGS_ADDR
For me U-boot must saved the device tree get from FIT with the needed
fixup in
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR ..
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS
=> loaded by SPL in CONFIG_SYS_SPL_ARGS_ADDR in mmc_load_image_raw_os()
and this FDT is used to start Linux in falscon mode with
spl_image.arg (at least when OP-TEE is not present)
I am working of suport on all my working branch (WIP)
https://github.com/u-boot/u-boot/compare/master...patrickdelaunay:spl_optee_W2140
fdt_support: Implement fdt_ethernet_set_macaddr()
arm: stm32mp: bsec: Update OTP shadow registers in SPL
arm: stm32mp: Factor out reading MAC address from OTP
stm32mp1: spl: Configure MAC address when booting OP-TEE
lib: Makefile: Make optee library available in SPL
ARM: dts: stm32mp: Add OP-TEE "/firmware" node to SPL dtb
stm32mp1: spl: Copy optee nodes to target FDT for OP-TEE payloads
README| 4 -
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 3 +
arch/arm/mach-stm32mp/bsec.c | 4 +-
arch/arm/mach-stm32mp/cpu.c | 59 --
.../arm/mach-stm32mp/include/mach/sys_proto.h | 3 +
arch/arm/mach-stm32mp/spl.c | 3 +
board/st/stm32mp1/spl.c | 53 +
common/fdt_support.c | 30 +++
common/spl/Kconfig| 11 ++
configs/am335x_boneblack_vboot_defconfig | 1 +
configs/am335x_evm_defconfig | 1 +
configs/am335x_igep003x_defconfig | 1 +
configs/am335x_shc_defconfig | 1 +
configs/am335x_shc_ict_defconfig | 1 +
configs/am335x_shc_netboot_defconfig | 1 +
configs/am335x_shc_sdboot_defconfig | 1 +
configs/am335x_sl50_defconfig | 1 +
configs/am3517_evm_defconfig | 1 +
configs/am43xx_evm_defconfig | 1 +
configs/am43xx_evm_rtconly_defconfig | 1 +
configs/am43xx_evm_usbhost_boot_defconfig | 1 +
configs/am57xx_evm_defconfig | 1 +
configs/devkit8000_defconfig | 1 +
configs/display5_defconfig
Re: [Uboot-stm32] [PATCH v2 03/11] stm32mp1: Add support for falcon mode boot from SD card
Hi,
On 9/8/21 1:59 AM, Alexandru Gagniuc wrote:
Falcon mode requires a board-specific mechanism to select between
fast and normal boot. This is done via spl_start_uboot()
Use the USER2 button as the selection mechanism. This is connected to
GPIO PA13. This GPIO is already accessible via the "st,fastboot-gpios"
devicetree node, but is is also aliased as "u-boot,falcon-gpios". This
is the only button on DK2 which accessible simultaneously to the RESET
button. USER2 is too close, and I can't fit my fingers to press both.
The fact that USER2 is also used for android fastboot is of no
consequence. One can let go of USER2 after SPL but before being
sampled by u-boot. If that is missed, it's okay, u-boot tries to
initialize the ethernet, which can be stopped with a Ctr-C. This
conveniently opens up a u-boot shell.
Offsets for raw MMC loading are defined. These point to the partition
after "ssbl". Offsets for SPI are not defined, and thus SPL_LOAD_SPI
must be disabled to avoid a build failure. The only way to accommodate
this is to add a new defconfig, adventurously named stm32mp1_falcon.
The baudrate is set to 2 Mbaud, as the point of this config is to boot
fast. The default devicetree is set to -dk2. This is because EV1 does
not have a crypto-enabled CPU, and thus enabling ECDSA support would
have made far less sense. That and all the goodies with FIT in SPL
are enabled to give this config some continuous integration TLC.
Signed-off-by: Alexandru Gagniuc
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 2 +
board/st/stm32mp1/spl.c | 39 +
configs/stm32mp15_falcon_defconfig | 181 +++
3 files changed, 222 insertions(+)
create mode 100644 configs/stm32mp15_falcon_defconfig
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 0101962ea5..b314ce2dac 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -16,6 +16,8 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
+ /* This is the same as fastboot-gpios. This is on purpose */
+ u-boot,falcon-gpios = <&gpioa 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
st,fastboot-gpios = <&gpioa 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
diff --git a/board/st/stm32mp1/spl.c b/board/st/stm32mp1/spl.c
index 8e4549a1b3..921d0190e0 100644
--- a/board/st/stm32mp1/spl.c
+++ b/board/st/stm32mp1/spl.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include "../common/stpmic1.h"
@@ -29,6 +30,44 @@ int board_early_init_f(void)
return 0;
}
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT)
+int spl_start_uboot(void)
+{
+ ofnode node;
+ struct gpio_desc gpio;
+ int boot_uboot = 1;
+
+ node = ofnode_path("/config");
+ if (!ofnode_valid(node)) {
+ pr_warn("%s: no /config node?\n", __func__);
+ return 0;
+ }
+
+ if (gpio_request_by_name_nodev(node, "u-boot,falcon-gpios", 0, &gpio,
+ GPIOD_IS_IN)) {
+ pr_warn("%s: could not find a /config/u-boot,falcon-gpios\n",
+ __func__);
+ return 1;
+ }
+
+ boot_uboot = dm_gpio_get_value(&gpio);
+ dm_gpio_free(NULL, &gpio);
+
+ return boot_uboot;
+}
+
I don't like the duplicated function for one key...
To avoid conflict with GPIO key already used for other purpose fastboot,
the Falcon mode activation can also use U-Boot environment
=> benefit:
1/ U-Boot can be requested by Linux before reset (set env boot_os=0)
2/ for first boot, the U-Boot is started to execute "spl export" before
to set "boot_os=1"
And / or with console to force U-Boot as it is done by many other board
(check 'c' character)
/*
* Return
* 0 if booting into OS is selected
* 1 if booting into U-Boot is selected
*/
intspl_start_uboot(void)
{/* Break into full U-Boot on 'c' */ if (serial_tstc() && serial_getc()
== 'c') return 1;
/* check environment for falcon mode activation */
env_init();
if(env_get_yesno("boot_os") != 0)
return0;
return1;
}
+#if IS_ENABLED(CONFIG_ARMV7_NONSEC)
+/*
+ * A bit of a hack, but armv7_boot_nonsec() is provided by bootm.c. This is not
+ * available in SPL, so we have to provide an implementation.
+ */
+bool armv7_boot_nonsec(void)
+{
+ return 0;
+}
This hack can be avoid => CONFIG_ARMV7_NONSEC not activated
U-Boot is running in normal world after OP-TEE / loaded by SPL :
it is the same for PSCI / SCMI support !
config STM32MP15x
bool "Support STMicroelectronics STM32MP15x Soc"
select ARCH_SUPPORT_PSCI if !TFABOOT && !SPL_OPTEE_IMAGE
select ARM_SMCCC if TFABOOT || SPL_OPTEE_IMAG
Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On 10/4/21 05:44, AKASHI Takahiro wrote: # Resending the RFC as some of patches were deplicately submitted. # See also https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/dm_disk The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot device model. In the past, I poposed a couple of patch series, the latest one[1], while Heinrich revealed his idea[2], and the approach taken here is something between them, with a focus on block device handlings. # The code is a PoC and not well tested yet. Disks in UEFI world: In general in UEFI world, accessing to any device is performed through a 'protocol' interface which are installed to (or associated with) the device's UEFI handle (or an opaque pointer to UEFI object data). Protocols are implemented by either the UEFI system itself or UEFI drivers. For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk hereafter). Currently, every efi_disk may have one of two origins: a.U-Boot's block devices or related partitions (lib/efi_loader/efi_disk.c) b.UEFI objects which are implemented as a block device by UEFI drivers. (lib/efi_driver/efi_block_device.c) All the efi_diskss as (a) will be enumelated and created only once at UEFI subsystem initialization (efi_disk_register()), which is triggered by first executing one of UEFI-related U-Boot commands, like "bootefi", "setenv -e" or "efidebug". EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) in the corresponding udevice(UCLASS_BLK). On the other hand, efi_disk as (b) will be created each time UEFI boot services' connect_controller() is executed in UEFI app which, as a (device) controller, gives the method to access the device's data, ie. EFI_BLOCK_IO_PROTOCOL. more details >>> Internally, connect_controller() search for UEFI driver that can support this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, then calls the driver's 'bind' interface, which eventually installs the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for * creating additional partitions efi_disk's, and * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. <<< <<< Issues: === 1. While an efi_disk represents a device equally for either a whole disk or a partition in UEFI world, the device model treats only a whole disk as a real block device or udevice(UCLASS_BLK). 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc in plat_data is supposed to be private and not to be accessed outside the device model. # This issue, though, exists for all the implmenetation of U-Boot # file systems as well. For efi_disk(a), 3. A block device can be enumelated dynamically by 'scanning' a device bus in U-Boot, but UEFI subsystem is not able to update efi_disks accordingly. For examples, => scsi rescan; efidebug devices => usb start; efidebug devices ... (A) (A) doesn't show any usb devices detected. => scsi rescan; efidebug boot add -b 0 TEST scsi 0:1 ... => scsi rescan ... (B) => bootefi bootmgr ... (C) (C) may de-reference a bogus blk_desc pointer which has been freed by (B). (Please note that "scsi rescan" removes all udevices/blk_desc and then re-create them even if nothing is changed on a bus.) For efi_disk(b), 4. A controller (handle), combined with efi_block driver, has no corresponding udevice as a parent of efi_disks in DM tree, unlike, say, a scsi controller, even though it provides methods for block io perations. 5. There is no way supported to remove efi_disk's even after disconnect_controller() is called. My approach in this RFC: Due to functional differences in semantics, it would be difficult to identify "udevice" structure as a handle in UEFI world. Instead, we will have to somehow maintain a relationship between a udevice and a handle. 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions Currently, the uclass for paritions is not a UCLASS_BLK. It can be possible to define partitions as UCLASS_BLK (with IF_TYPE_PARTION?), but I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) is tightly coupled with 'struct blk_desc' data which is still used as a "structure to a whole disk" in a lot of interfaces. (I hope that you understand what it means.) In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent: For instance, UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION (IF_TYPE_SCSI)| +- struct blk_desc +- struct disk_part +- scsi_blk_ops +- blk_part_ops 1-2. create partition udevices in the context of device_probe() part_init() is already called in blk_post_probe(). See the commit d0851c8
Re: [PATCH] mmc: zynq_sdhci: Add xilinx_pm_request weak function
On 10/1/21 1:08 PM, T Karthik Reddy wrote:
> Mini emmc does not use any pmufw and ZYNQMP_FIRMWARE is disabled.
> xilinx_pm_request() will not be compiled and causes undefined reference to
> `xilinx_pm_request' error. So add a weak function in zynq_sdhci.c file.
>
> Signed-off-by: T Karthik Reddy
> Signed-off-by: Ashok Reddy Soma
> ---
>
> drivers/mmc/zynq_sdhci.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index c94825dceb..5cea4c695e 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -69,6 +69,12 @@ __weak int zynqmp_mmio_write(const u32 address, const u32
> mask, const u32 value)
> return 0;
> }
>
> +__weak int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32 arg2,
> + u32 arg3, u32 *ret_payload)
> +{
> + return 0;
> +}
> +
> #if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL)
> /* Default settings for ZynqMP Clock Phases */
> static const u32 zynqmp_iclk_phases[] = {0, 63, 63, 0, 63, 0,
>
Applied.
M
[PATCH] common: Kconfig: use 'vidconsole' name instead of old 'video'
After DM_VIDEO conversion the 'vidconsole' is the correct name for the frame buffer console. 'video' will not work, so update the description of the config option. Signed-off-by: Anatolij Gustschin --- common/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index ee14d3ad5b..1275c9b1b9 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -182,8 +182,8 @@ config SYS_CONSOLE_IS_IN_ENV default y if CONSOLE_MUX help This allows multiple input/output devices to be set at boot time. - For example, if stdout is set to "serial,video" then output will - be sent to both the serial and video devices on boot. The + For example, if stdout is set to "serial,vidconsole" then output + will be sent to both the serial and video devices on boot. The environment variables can be updated after boot to change the input/output devices. -- 2.17.1
Re: imx6 DM_VIDEObroken
On Wed, 29 Sep 2021 09:33:18 -0700 Tim Harvey thar...@gateworks.com wrote: ... > One last question on this. I have never used U-Boot vidconsole before. > It does work if I 'setenv stdout serial,videconsole' but if I saveenv > and reboot vidconsole is not enabled. Should I expect it to be or is > it expected that if you want vidconsole you need to do a setenv in > preboot? if you have CONFIG_CONSOLE_MUX=y CONFIG_SYS_CONSOLE_IS_IN_ENV=y and # CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE is not set then vidconsole should be enabled. -- Anatolij
Re: [PATCH] sf: Querying write-protect status before operating the flash
On 13.09.21 09:48, Jan Kiszka wrote: > Hi all, > > Chao, please no top-post on mailing list. Also check your mail client, > it seems to inject a lot of bogus newlines. > > On 08.09.21 06:55, chaochao2021666 wrote: >> >> >> >> HI Jagan >> >> >> >> sorry for the delay response. >> >> >> And I have checked the maser. There is still a problem with this feature。 >> >> >> reproduce steps: >> 1. enable the flash protect function >> 2. using sf cmd to erase the flash. I can get the erase "OK",not the "error". >> >> >> >> I think the root cause is that the detection mechanism is missing and to >> judge the permissions of the action >> >> So pull this PR to improve the erase flow >> >> >> another question: >> how can I visit the u-boot-spi/next? do there any link? >> > > See MAINTAINERS: https://source.denx.de/u-boot/custodians/u-boot-spi.git > > But also that tree contains no usage of the flash_is_locked callback. > That was once evaluated by drivers/mtd/spi/spi_flash.c but then > forgotten in the new SPI NOR framework it seems. > > Chao's patch makes sense to me to restore this feature. > > Jan > >> >> >> >> >> BRs >> Chao >> >> >> >> At 2021-06-29 21:50:28, "Jagan Teki" wrote: >>> On Tue, Jun 22, 2021 at 10:51 AM chao zeng wrote: From: Chao Zeng When operating the write-protection flash,spi_flash_std_write() and spi_flash_std_erase() would return wrong result.The flash is protected, but write or erase the flash would show "OK". Check the flash write protection state if the write-protection has enbale before operating the flash. Signed-off-by: Chao Zeng --- >>> >>> Does it broken on master? if yes can you check in u-boot-spi/next? >>> >>> Jagan. > Ping - how do we proceed here? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] mtd: cqspi: Fix division by zero
On Tue, Sep 14, 2021 at 05:21:48AM +0200, Marek Vasut wrote:
> Both dummy.nbytes and dummy.buswidth may be zero. By not checking
> the later, it is possible to trigger division by zero and a crash.
> This does happen with tiny SPI NOR framework in SPL. Fix this by
> adding the check and returning zero dummy bytes in such a case.
>
> Fixes: 38b0852b0ea ("spi: cadence-qspi: Add support for octal DTR flashes")
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Vignesh R
> Cc: Pratyush Yadav
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [Uboot-stm32] [PATCH v2 01/11] spl: Move SYS_MMCSD_RAW_MODE_KERNEL_SECTOR to Kconfig
Hi, On 9/8/21 1:59 AM, Alexandru Gagniuc wrote: Although Falcon mode is very useful in improving boot speed, its implementation is quite antiquated. A question that Falcon mode asks is "Where do I look for the kernel". With MMC boot media, the correct answer is CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. There are a few things to be said about the wisdom of using a raw sector as opposed to more elegant schemes. However, changing how falcon mode works is beyond the scope of this change. Signed-off-by: Alexandru Gagniuc --- README | 4 common/spl/Kconfig | 11 +++ configs/am335x_boneblack_vboot_defconfig | 1 + configs/am335x_evm_defconfig | 1 + configs/am335x_igep003x_defconfig | 1 + configs/am335x_shc_defconfig | 1 + configs/am335x_shc_ict_defconfig | 1 + configs/am335x_shc_netboot_defconfig | 1 + configs/am335x_shc_sdboot_defconfig | 1 + configs/am335x_sl50_defconfig | 1 + configs/am3517_evm_defconfig | 1 + configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_rtconly_defconfig | 1 + configs/am43xx_evm_usbhost_boot_defconfig | 1 + configs/am57xx_evm_defconfig | 1 + configs/devkit8000_defconfig | 1 + configs/display5_defconfig | 1 + configs/display5_factory_defconfig | 1 + configs/dra7xx_evm_defconfig | 1 + configs/gwventana_emmc_defconfig | 1 + configs/gwventana_gw5904_defconfig | 1 + configs/gwventana_nand_defconfig | 1 + configs/igep00x0_defconfig | 1 + configs/imx6dl_mamoj_defconfig | 1 + configs/imx6q_logic_defconfig | 1 + configs/imx6qdl_icore_mipi_defconfig | 1 + configs/imx6qdl_icore_mmc_defconfig | 1 + configs/imx6qdl_icore_rqs_defconfig | 1 + configs/mccmon6_nor_defconfig | 1 + configs/omap35_logic_defconfig | 1 + configs/omap35_logic_somlv_defconfig | 1 + configs/omap3_logic_defconfig | 1 + configs/omap3_logic_somlv_defconfig | 1 + configs/omap4_panda_defconfig | 1 + configs/omap5_uevm_defconfig | 1 + include/configs/brppt1.h | 1 - include/configs/devkit8000.h | 2 -- include/configs/display5.h | 1 - include/configs/embestmx6boards.h | 1 - include/configs/gw_ventana.h | 1 - include/configs/imx6-engicam.h | 1 - include/configs/imx6_logic.h | 1 - include/configs/imx6dl-mamoj.h | 1 - include/configs/ls1043ardb.h | 1 - include/configs/mccmon6.h | 1 - include/configs/mx6sabreauto.h | 1 - include/configs/mx6sabresd.h | 1 - include/configs/pico-imx6.h | 1 - include/configs/pico-imx6ul.h | 1 - include/configs/pico-imx7d.h | 1 - include/configs/sama5d3_xplained.h | 1 - include/configs/tam3517-common.h | 1 - include/configs/ti_armv7_common.h | 1 - include/configs/vyasa-rk3288.h | 1 - include/configs/xea.h | 1 - include/configs/xilinx_zynqmp.h | 1 - include/configs/zynq-common.h | 1 - scripts/config_whitelist.txt | 1 - 58 files changed, 44 insertions(+), 28 deletions(-) diff --git a/README b/README index 1c1db98098..7df53a9861 100644 --- a/README +++ b/README @@ -2182,10 +2182,6 @@ The following options need to be configured: Partition on the MMC to load U-Boot from when the MMC is being used in raw mode - CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR - Sector to load kernel uImage from when MMC is being - used in raw mode (for Falcon mode) - CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS Sector and number of sectors to load kernel argument diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c155a3b5fc..1c6b57af49 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -990,6 +990,17 @@ config SYS_OS_BASE endif # SPL_OS_BOOT +config SYS_MMCSD_RAW_MODE_KERNEL_SECTOR + hex "Falcon mode: Sector to load kernel uImage from MMC" + default 0x0 + depends on SPL_OS_BOOT + help + When Falcon mode is used with an MMC or SD media, SPL needs to know + where to look for the kernel uImage. The image is expected to begin + at the raw MMC specified in this config. + Note that the Falcon mode image can also be a FIT, if FIT support is + enabled. + The define will be activated for all the board ... with default value 0x0 !? So the code in mmc_load_image_raw_os() will be activated (the SPL behavior change): #if defined(CONFIG_SYS_MMCSD_RAW
[PATCH 2/2] arm: mvebu: mvebu_armada-8k: drop Puzzle M801 early init code
Since the CP1 pinctrl is not properly set in the DTS, there is no
need for setting the pinctrl by writing hardcoded values to the MPP
registers.
So, drop the code relating to that.
Fixes: 87c220d0 ("arm: mvebu: mvebu_armada-8k: Add support for initializing iEi
Puzzle-M801 networking")
Signed-off-by: Robert Marko
---
board/Marvell/mvebu_armada-8k/board.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/board/Marvell/mvebu_armada-8k/board.c
b/board/Marvell/mvebu_armada-8k/board.c
index 7da5d9f96b..77c7dd7ab0 100644
--- a/board/Marvell/mvebu_armada-8k/board.c
+++ b/board/Marvell/mvebu_armada-8k/board.c
@@ -35,17 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_IO_REG_CL ((1 << I2C_IO_REG_0_USB_H0_CL) | \
(1 << I2C_IO_REG_0_USB_H1_CL))
-/*
- * Information specific to the iEi Puzzle-M801 board.
- */
-
-/* Internal configuration registers */
-#define CP1_CONF_REG_BASE 0xf444
-#define CONF_REG_MPP0 0x0
-#define CONF_REG_MPP1 0x4
-#define CONF_REG_MPP2 0x8
-#define CONF_REG_MPP3 0xC
-
static int usb_enabled = 0;
/* Board specific xHCI dis-/enable code */
@@ -153,14 +142,7 @@ int board_xhci_enable(fdt_addr_t base)
int board_early_init_f(void)
{
- /* Initialize some platform specific memory locations */
- if (of_machine_is_compatible("marvell,armada8040-puzzle-m801")) {
- /* MPP setup */
- writel(0x0044, CP1_CONF_REG_BASE + CONF_REG_MPP0);
- writel(0x, CP1_CONF_REG_BASE + CONF_REG_MPP1);
- writel(0x, CP1_CONF_REG_BASE + CONF_REG_MPP2);
- writel(0x0000, CP1_CONF_REG_BASE + CONF_REG_MPP3);
- }
+ /* Nothing to do yet */
return 0;
}
--
2.32.0
[PATCH 1/2] arm: mvebu: dts: m801: correct CP1 pinctrl
Current CP1 pinctrl that is set on the Puzzle M801 is incorrect.
CP1 pins are only used for the SMI bus and the MSS I2C, all other
pins are just GPIO-s.
Due to this being set completely wrong, the pinctrl was actually
ended up being hardcoded in the board_early_init_f() step so that
SMI would work.
That is obviously not the right thing to do, so convert the register
hex values that were being written to individual pin modes and set it
in the DTS.
Add the SMI pins to the CP1 MDIO node as otherwise CP1 pinctrl does
not get probed without an consumer.
Fixes: 2ae2b8a2 ("arm: mvebu: Initial iEi Puzzle-M801 support")
Signed-off-by: Robert Marko
---
arch/arm/dts/armada-8040-puzzle-m801.dts | 36 ++--
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/arch/arm/dts/armada-8040-puzzle-m801.dts
b/arch/arm/dts/armada-8040-puzzle-m801.dts
index 510fb84d5a..9e714c33e9 100644
--- a/arch/arm/dts/armada-8040-puzzle-m801.dts
+++ b/arch/arm/dts/armada-8040-puzzle-m801.dts
@@ -243,6 +243,9 @@
&cp1_mdio {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&cp1_smi_pins>;
+
cp1_ge_phy0: ethernet-phy@3 {
reg = <1>;
};
@@ -292,33 +295,24 @@
/*
* MPP Bus:
* [0-5] TDM
-* [6,7] CP1_UART 0
-* [8] CP1 10G SFP LOS
-* [9] CP1 10G PHY RESET
-* [10] CP1 10G SFP TX Disable
-* [11] CP1 10G SFP Mode
-* [12] SPI1 CS1n
-* [13] SPI1 MISO (TDM and SPI ROM shared)
-* [14] SPI1 CS0n
-* [15] SPI1 MOSI (TDM and SPI ROM shared)
-* [16] SPI1 CLK (TDM and SPI ROM shared)
-* [24] CP1 2.5G SFP TX Disable
-* [26] CP0 10G SFP TX Fault
-* [27] CP0 10G SFP Mode
-* [28] CP0 10G SFP LOS
-* [29] CP0 10G SFP TX Disable
-* [30] USB Over current indication
-* [31] 10G Port 0 phy reset
+* [27-28] SMI
+* [29-30] CP1 MSS I2C
+* [6-26, 31] GPIO
* [32-62] = 0xff: Keep default CP1_shared_pins:
*/
/* 0123456789 */
- pin-func = < 0x4 0x4 0x4 0x4 0x4 0x4 0x8 0x8 0x0 0x0
-0x0 0x0 0x3 0x3 0x3 0x3 0x3 0xff 0xff 0xff
-0xff 0xff 0xff 0xff 0x0 0xff 0x0 0x0 0x0 0x0
-0x0 0x0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ pin-func = < 0x4 0x4 0x4 0x4 0x4 0x4 0x0 0x0 0x0 0x0
+0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
+0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x8 0x8 0x8
+0x8 0x0 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff>;
+
+ cp1_smi_pins: cp1-smi-pins {
+ marvell,pins = < 27 28 >;
+ marvell,function = <8>;
+ };
};
&ap_spi0 {
--
2.32.0
Re: [PATCH v5 4/5] env: Allow environment files to use the C preprocessor
Dear Simon Glass, In message <20211001183842.v5.4.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you wrote: > In many cases environment variables need access to the U-Boot CONFIG > variables to select different options. Enable this so that the environment > scripts can be as useful as the ones currently in the board config files. > > Also support += to allow variables to be appended to. This is needed when > using the preprocessor. > > Signed-off-by: Simon Glass > --- > > (no changes since v4) > > Changes in v4: > - Add documentation in rST format instead of README > - Move use of += to this patch > - Explain that environment variables may not end in + Sorry, I disagree here. There was intentionally only very little restrictions on what a environment variable name should look like - the only exceptions were the '=' and the NUL characters. Adding artificial restrictions now just to enable your custom notation for appending seems not acceptable to me. You might want to chose a different notation or implement a proper parser instead. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never call a man a fool. Borrow from him.
Re: [PATCH v5 3/5] env: Allow U-Boot scripts to be placed in a .env file
Dear Simon, In message <20211001183842.v5.3.If789ba3e2667c46c03eda3386ca84a863baeda55@changeid> you wrote: > > Add a feature that brings in a .env file associated with the board > config, if present. To use it, create a file in a board//env > directory called .env (or common.env if you want the same > environment for all boards). This should be no exclusive "or" here. If a common.env exists, it should be used for all boards, and if additionally one ore more .env files exist, these should ALSO be applied to the respective boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Save yourself! Reboot in 5 seconds!
Re: [PATCH v5 2/5] doc: Move environment documentation to rST
Dear Simon, In message <20211002003848.1803446-3-...@chromium.org> you wrote: > > +baudrate > +see CONFIG_BAUDRATE > + > +bootdelay > +see CONFIG_BOOTDELAY > + > +bootcmd > +see CONFIG_BOOTCOMMAND I know you only copied this, but the text is actually not helpful, as it does not even mention where to look for documentation for these CONFIG_* options > +autoload > +if set to "no" (any string beginning with 'n'), > +"bootp" will just load perform a lookup of the > +configuration from the BOOTP server, but not try to > +load any image using TFTP We should add "dhcp" here, too. > +autostart > +if set to "yes", an image loaded using the "bootp", > +"rarpboot", "tftpboot" or "diskboot" commands will > +be automatically started (by internally calling > +"bootm") > + > +If set to "no", a standalone image passed to the > +"bootm" command will be copied to the load address > +(and eventually uncompressed), but NOT be started. > +This can be used to load and uncompress arbitrary > +data. There is a consistency problem here. In "bootm" (cmd/bootm.c), the "yes" part applies - any other value or the variable not being defined omitting the call of do_bootm(). This also applies to nandboot, btw. In "bootelf" (cmd/elf.c), the "no" part applies - any other value or the variable not being defined will cause do_bootelf_exec() to be called. This should be both documented and fixed. > +ipaddr > +IP address; needed for tftpboot command ...and for ping etc. > +vlan > +When set to a value < 4095 the traffic over > +Ethernet is encapsulated/received over 802.1q > +VLAN tagged frames. Really? I can't see where "vlan" is actually used in the code. [I looked for it because I could not remember if the values is interpreted as decimal or hex number...] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Systems programmers are the high priests of a low cult. -- R.S. Barton
[PATCH] Revert "configs: stm32mp1: only support SD card after NOR in bootcmd_stm32mp"
This reverts commit d5d726d3cc47691ace3c68fa31147ad104aaf579,
which breaks boards which ship with multiple SD/eMMC sockets.
This stm32mp1.h config is not used only by the ST reference
boards, but all the other STM32MP1 based boards in U-Boot, so
changes to this stm32mp1.h cannot break the other boards.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
NOTE: I think we might need to split out the env for different
boards into different headers instead. Thoughts ?
---
include/configs/stm32mp1.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 973a4f1d4b8..a75ed693f57 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -120,7 +120,7 @@
* for serial/usb: execute the stm32prog command
* for mmc boot (eMMC, SD card), boot only on the same device
* for nand or spi-nand boot, boot with on ubifs partition on UBI partition
- * for nor boot, use SD card = mmc0
+ * for nor boot, use the default order
*/
#define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
"echo \"Boot over ${boot_device}${boot_instance}!\";" \
@@ -133,8 +133,6 @@
"if test ${boot_device} = nand ||" \
" test ${boot_device} = spi-nand ;" \
"then env set boot_targets ubifs0; fi;" \
- "if test ${boot_device} = nor;" \
- "then env set boot_targets mmc0; fi;" \
"run distro_bootcmd;" \
"fi;\0"
--
2.33.0
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
Am 2021-10-04 12:31, schrieb Frieder Schrempf: On 30.09.21 23:08, Michael Walle wrote: Printing a warning might scare users, though. I'd prefer to fix the online help, where only "erase and write" is mentioned. Which document are you referring to? I don't really see the "sf" command documented anywhere. the "sf update" online help: "sf update addr offset|partition len- erase and write `len' bytes from memory\n" " at `addr' to flash at `offset'\n" " or to start of mtd `partition'\n" -michael
Re: [PATCH v2 0/4] Add reset support to HiFive Unmatched
On Fri, Sep 24, 2021 at 10:42 AM Alexandre Ghiti wrote: > > As there is no GPIO to reset the HiFive Unmatched board, we must directly > ask the da9063 PMIC for a reset: this small patchset adds the corresponding > sysreset driver and enables it for this board. > > As the probing of this new device depends on a device-tree node, this > series also adds the device tree bindings documentation for the da9063 > device. > > Changes in v2: > - Add device tree probing as suggested by Heinrich > - Rebased onto master > > Alexandre Ghiti (4): > dt-bindings: power: Add da9063 PMIC device bindings > dt-bindings: power: Add new da9063 sysreset subdevice bindings > drivers: pmic: Add sysreset driver for da9063 PMIC > riscv: Enable da9063 sysreset driver on HiFive Unmatched > > arch/riscv/dts/hifive-unmatched-a00.dts | 4 ++ > configs/sifive_unmatched_defconfig| 2 + > doc/device-tree-bindings/power/da9063.txt | 68 +++ > drivers/power/pmic/da9063.c | 51 - > include/power/da9063_pmic.h | 1 + > 5 files changed, 125 insertions(+), 1 deletion(-) > create mode 100644 doc/device-tree-bindings/power/da9063.txt > > -- > 2.30.2 > The i2c sequence proposed here should not work according to Adam in this thread: https://patchwork.kernel.org/project/linux-riscv/patch/20210921053356.1705833-1-alexandre.gh...@canonical.com/. According to Adam, the sequence he proposed should be SiFive Unmatched board-specific, as this is not something other boards could use. I'll be back with a v3, you can drop this. Thanks, Alex
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
On 30.09.21 23:21, Michael Walle wrote:
> Am 2021-09-30 18:19, schrieb Frieder Schrempf:
>> From: Frieder Schrempf
>>
>> Currently 'sf update' supports only offsets that are aligned to the
>> erase block size of the serial flash. Unaligned offsets result in
>> something like:
>>
>> => sf update ${kernel_addr_r} 0x400 ${filesize}
>> device 0 offset 0x400, size 0x11f758
>> SPI flash failed in erase step
>>
>> In order to support unaligned updates, we simply read the first full
>> block and check only the requested part of the block for changes. If
>> necessary, the block is erased, the first (unchanged) part of the block
>> is written back together with the second part of the block (updated
>> data).
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> cmd/sf.c | 17 +++--
>> 1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/cmd/sf.c b/cmd/sf.c
>> index eac27ed2d7..c54b4b10bb 100644
>> --- a/cmd/sf.c
>> +++ b/cmd/sf.c
>> @@ -171,30 +171,32 @@ static int do_spi_flash_probe(int argc, char
>> *const argv[])
>> static const char *spi_flash_update_block(struct spi_flash *flash,
>> u32 offset,
>> size_t len, const char *buf, char *cmp_buf, size_t *skipped)
>> {
>> + u32 offset_aligned = ALIGN_DOWN(offset, flash->sector_size);
>> + u32 sector_offset = offset - offset_aligned;
>> char *ptr = (char *)buf;
>>
>> debug("offset=%#x, sector_size=%#x, len=%#zx\n",
>> offset, flash->sector_size, len);
>> /* Read the entire sector so to allow for rewriting */
>> - if (spi_flash_read(flash, offset, flash->sector_size, cmp_buf))
>> + if (spi_flash_read(flash, offset_aligned, flash->sector_size,
>> cmp_buf))
>> return "read";
>> /* Compare only what is meaningful (len) */
>> - if (memcmp(cmp_buf, buf, len) == 0) {
>> + if (memcmp(cmp_buf + sector_offset, buf, len) == 0) {
>> debug("Skip region %x size %zx: no change\n",
>> offset, len);
>> *skipped += len;
>> return NULL;
>> }
>> /* Erase the entire sector */
>> - if (spi_flash_erase(flash, offset, flash->sector_size))
>> + if (spi_flash_erase(flash, offset_aligned, flash->sector_size))
>> return "erase";
>> /* If it's a partial sector, copy the data into the temp-buffer */
>> if (len != flash->sector_size) {
>> - memcpy(cmp_buf, buf, len);
>> + memcpy(cmp_buf + sector_offset, buf, len);
>> ptr = cmp_buf;
>> }
>> /* Write one complete sector */
>> - if (spi_flash_write(flash, offset, flash->sector_size, ptr))
>> + if (spi_flash_write(flash, offset_aligned, flash->sector_size, ptr))
>> return "write";
>>
>> return NULL;
>> @@ -230,7 +232,10 @@ static int spi_flash_update(struct spi_flash
>> *flash, u32 offset,
>> ulong last_update = get_timer(0);
>>
>> for (; buf < end && !err_oper; buf += todo, offset += todo) {
>> - todo = min_t(size_t, end - buf, flash->sector_size);
>> + if (offset % flash->sector_size)
>
> do_div() to avoid linking errors on some archs, I guess.
Ok, will fix it.
>
>> + todo = flash->sector_size - (offset %
>> flash->sector_size);
>
> This is missing the end-buf calculation, no? I.e. if you update just one
> sector at an offset and the data you write is smaller than "sector_size
> - offset".
Indeed, thanks for catching this.
>
>> + else
>> + todo = min_t(size_t, end - buf, flash->sector_size);
>> if (get_timer(last_update) > 100) {
>> printf(" \rUpdating, %zu%% %lu B/s",
>> 100 - (end - buf) / scale,
>
> -michael
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
On 30.09.21 23:08, Michael Walle wrote: > Am 2021-09-30 19:17, schrieb Frieder Schrempf: >> On 30.09.21 18:35, Michael Walle wrote: >>> Am 2021-09-30 18:19, schrieb Frieder Schrempf: In order to support unaligned updates, we simply read the first full block and check only the requested part of the block for changes. If necessary, the block is erased, the first (unchanged) part of the block is written back together with the second part of the block (updated data). >>> >>> I'm not sure what I should think of this. You might loose that unchanged >>> part if there is an power loss in the middle, even worse, you likely >>> don't >>> have this part anymore because it isn't part of the data you want to >>> write >>> to the flash. >>> >>> Maybe add an parameter for allow (unsafe) unaligned updates? >>> >>> Now you might argue, that with "sf erase, sf write" you can do the same >>> harm, to which i reply: but then it is intentional ;) Because "sf erase" >>> just works on sector boundaries (which isn't really checked in the >>> command, >>> i just realized, but at least my driver returns EINVAL) and then the >>> user has to include the "unchanged part" for the arguments on the >>> commandline. >> >> True, but "sf update" already is "unsafe" even without supporting >> unaligned start offsets. The code already handles partial sector writes >> for the last sector in the same way (read, erase, write), which is also >> prone to data loss in case of power loss. > > Ah, I missed that. Yes, in this case, we don't loose anything. Agreed. > >> So this patch in fact just adds support for partial sector updates for >> the first sector. It is slightly more probable to loose data, but it >> doesn't introduce new "unsafe" behavior. >> >> Maybe we could cover this by adding a warning to the documentation, or >> even printing a warning? > > Heh, although I was using "sf update" all the time, I wasn't aware of > the read - "partly modify" - write cycle. Maybe it's just me being > over cautious. > > Printing a warning might scare users, though. I'd prefer to fix the > online help, where only "erase and write" is mentioned. Which document are you referring to? I don't really see the "sf" command documented anywhere.
[PATCH 1/6] scripts: remove some configs in config_whitelist.txt
Remove some config finishing by _ badly added by
scripts/build-whitelist.sh when joker is used in comments.
for example:
doc/uImage.FIT/command_syntax_extensions.txt:
... #ifdef CONFIG_OF_* | ...
cmd/nvedit.c:# error Define one of CONFIG_ENV_IS_IN_{EEPROM| \
FLASH|MMC|FAT|EXT4|\
Remove also configs only used in comments:
- CONFIG_BOOGER in include/linux/kconfig.h
- CONFIG_COMMANDS
- CONFIG_INIT_IGNORE_ERROR
- CONFIG_REG_*
- CONFIG_HOTPLUG : drivers/watchdog/omap_wdt.c:18
Signed-off-by: Patrick Delaunay
---
arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h | 8
include/configs/M5235EVB.h | 2 +-
include/configs/dra7xx_evm.h | 1 -
scripts/config_whitelist.txt | 14 --
4 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
index ea2f113f98..df392a2714 100644
--- a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
+++ b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
@@ -11,7 +11,7 @@
#include
-/* CONFIG_REG_0 */
+/* CFG REG_0 */
#define CFG_REG_0_OFFSET 0xC
#define CFG_REG_ROM_READ_SHIFT 1
#define CFG_REG_ROM_READ_MASK (1 << 1)
@@ -22,18 +22,18 @@
#define CFG_REG_ROM_READ_START (1 << 1)
#define CFG_REG_ROM_READ_END (0 << 1)
-/* CONFIG_REG_2 */
+/* CFG REG_2 */
#define CFG_REG_2_OFFSET 0x14
#define CFG_REG_REFCLK_PERIOD_SHIFT0
#define CFG_REG_REFCLK_PERIOD_MASK (0x << 0)
#define CFG_REG_REFCLK_PERIOD 0x2EF
-/* CONFIG_REG_8 */
+/* CFG REG_8 */
#define CFG_REG_8_OFFSET 0x2C
#define CFG_IODELAY_UNLOCK_KEY 0x
#define CFG_IODELAY_LOCK_KEY 0xAAAB
-/* CONFIG_REG_3/4 */
+/* CFG REG_3/4 */
#define CFG_REG_3_OFFSET 0x18
#define CFG_REG_4_OFFSET 0x1C
#define CFG_REG_DLY_CNT_SHIFT 16
diff --git a/include/configs/M5235EVB.h b/include/configs/M5235EVB.h
index f983281cc1..b37c915538 100644
--- a/include/configs/M5235EVB.h
+++ b/include/configs/M5235EVB.h
@@ -54,7 +54,7 @@
#define CONFIG_SYS_I2C_PINMUX_CLR ~(GPIO_PAR_FECI2C_SCL_MASK |
GPIO_PAR_FECI2C_SDA_MASK)
#define CONFIG_SYS_I2C_PINMUX_SET (GPIO_PAR_FECI2C_SCL_I2CSCL |
GPIO_PAR_FECI2C_SDA_I2CSDA)
-/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */
+/* this must be included AFTER the definition of CONFIG COMMANDS (if any) */
#define CONFIG_BOOTFILE"u-boot.bin"
#ifdef CONFIG_MCFFEC
# define CONFIG_IPADDR192.162.1.2
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 361ee9663d..16766943ab 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -113,7 +113,6 @@
#define CONFIG_SYS_MAX_FLASH_SECT 512
#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT
#define CONFIG_SYS_FLASH_SIZE (64 * 1024 * 1024) /* 64 MB */
-/* #define CONFIG_INIT_IGNORE_ERROR */
#define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_FLASH_BASE (0x0800)
#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 61ae682dcd..ca043b2f26 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -75,10 +75,8 @@ CONFIG_BOARD_IS_OPENRD_ULTIMATE
CONFIG_BOARD_NAME
CONFIG_BOARD_POSTCLK_INIT
CONFIG_BOARD_SIZE_LIMIT
-CONFIG_BOOGER
CONFIG_BOOTFILE
CONFIG_BOOTMODE
-CONFIG_BOOTP_
CONFIG_BOOTP_BOOTFILESIZE
CONFIG_BOOTP_DHCP_REQUEST_DELAY
CONFIG_BOOTP_ID_CACHE_SIZE
@@ -147,7 +145,6 @@ CONFIG_CM_T3X
CONFIG_CM_T43
CONFIG_CM_TCRAM
CONFIG_COLDFIRE
-CONFIG_COMMANDS
CONFIG_COMMON_BOOT
CONFIG_COMPAT
CONFIG_CONS_EXTC_PINSEL
@@ -227,7 +224,6 @@ CONFIG_DNET_AUTONEG_TIMEOUT
CONFIG_DP_DDR_CTRL
CONFIG_DP_DDR_DIMM_SLOTS_PER_CTLR
CONFIG_DP_DDR_NUM_CTRLS
-CONFIG_DRAM_TIMINGS_
CONFIG_DRIVER_DM9000
CONFIG_DSP_CLUSTER_START
CONFIG_DWCDDR21MCTL
@@ -267,7 +263,6 @@ CONFIG_ENV_CALLBACK_LIST_STATIC
CONFIG_ENV_FLAGS_LIST_DEFAULT
CONFIG_ENV_FLAGS_LIST_STATIC
CONFIG_ENV_IS_EMBEDDED
-CONFIG_ENV_IS_IN_
CONFIG_ENV_MAX_ENTRIES
CONFIG_ENV_MIN_ENTRIES
CONFIG_ENV_OFFSET_OOB
@@ -460,7 +455,6 @@ CONFIG_HIKEY_GPIO
CONFIG_HITACHI_SX14
CONFIG_HOSTNAME
CONFIG_HOST_MAX_DEVICES
-CONFIG_HOTPLUG
CONFIG_HPS_ALTERAGRP_DBGATCLK
CONFIG_HPS_ALTERAGRP_MAINCLK
CONFIG_HPS_ALTERAGRP_MPUCLK
@@ -634,7 +628,6 @@ CONFIG_IMX6_PWM_PER_CLK
CONFIG_IMX_HDMI
CONFIG_IMX_VIDEO_SKIP
CONFIG_INETSPACE_V2
-CONFIG_INIT_IGNORE_ERROR
CONFIG_INI_ALLOW_MULTILINE
CONFIG_INI_CASE_INSENSITIVE
CONFIG_INI_MAX_LINE
@@ -943,7 +936,6 @@ CONFIG_NUM_DSP_CPUS
CONFIG_NUM_PAMU
CONFIG_ODROID_REV_AIN
CONFIG_OFF_PADCONF
-CONFIG_OF_
CONFIG_OMAP_EHCI_PHY1_RESET_GPIO
CONFIG_OMAP_EHCI_PHY2_RESET_GPIO
CONFIG_OMAP_EHCI_PHY3_RESET_GPIO
@@ -1073,10 +1065,6 @@ CONFIG_RD_LVL
CONFIG_REALMODE_DEBUG
CONFIG_RED_LED
CONFIG_REG
-CON
[PATCH 3/6] Remove unused CONFIG_NO_RELOCATION
Remove the latest reference of CONFIG_NO_RELOCATION in code Signed-off-by: Patrick Delaunay --- include/configs/thunderx_88xx.h | 1 - scripts/config_whitelist.txt| 1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/thunderx_88xx.h b/include/configs/thunderx_88xx.h index 1ce0347300..600689843b 100644 --- a/include/configs/thunderx_88xx.h +++ b/include/configs/thunderx_88xx.h @@ -58,7 +58,6 @@ /* Monitor Command Prompt */ #define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */ #define CONFIG_SYS_MAXARGS 64 /* max command args */ -#define CONFIG_NO_RELOCATION 1 #define PLL_REF_CLK5000/* 50 MHz */ #define NS_PER_REF_CLK_TICK(10/PLL_REF_CLK) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b125568a26..6479b49291 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -927,7 +927,6 @@ CONFIG_NON_SECURE CONFIG_NORBOOT CONFIG_NORFLASH_PS32BIT CONFIG_NO_ETH -CONFIG_NO_RELOCATION CONFIG_NO_WAIT CONFIG_NS16550_MIN_FUNCTIONS CONFIG_NS8382X -- 2.25.1
[PATCH 4/6] Remove unused CONFIG_SYS_FLASH_AMD_CHECK_DQ7
Remove the latest reference of CONFIG_SYS_FLASH_AMD_CHECK_DQ7 in code
Signed-off-by: Patrick Delaunay
---
include/configs/P2041RDB.h | 1 -
include/configs/corenet_ds.h | 1 -
scripts/config_whitelist.txt | 1 -
3 files changed, 3 deletions(-)
diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index 1e75066eb1..d17cdaadee 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -205,7 +205,6 @@ unsigned long get_board_sys_clk(unsigned long dummy);
#endif /* CONFIG_NAND_FSL_ELBC */
#define CONFIG_SYS_FLASH_EMPTY_INFO
-#define CONFIG_SYS_FLASH_AMD_CHECK_DQ7
#define CONFIG_SYS_FLASH_BANKS_LIST{CONFIG_SYS_FLASH_BASE_PHYS + 0x800}
#define CONFIG_HWCONFIG
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 79fca968dc..b79991f8c9 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -206,7 +206,6 @@
#endif /* CONFIG_NAND_FSL_ELBC */
#define CONFIG_SYS_FLASH_EMPTY_INFO
-#define CONFIG_SYS_FLASH_AMD_CHECK_DQ7
#define CONFIG_SYS_FLASH_BANKS_LIST{CONFIG_SYS_FLASH_BASE_PHYS +
0x800, CONFIG_SYS_FLASH_BASE_PHYS}
#define CONFIG_HWCONFIG
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 6479b49291..fe618ff39a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1713,7 +1713,6 @@ CONFIG_SYS_FLASH1_BASE_PHYS
CONFIG_SYS_FLASH1_BASE_PHYS_EARLY
CONFIG_SYS_FLASHBOOT
CONFIG_SYS_FLASH_ADDR_BASE
-CONFIG_SYS_FLASH_AMD_CHECK_DQ7
CONFIG_SYS_FLASH_AUTOPROTECT_LIST
CONFIG_SYS_FLASH_BANKS_LIST
CONFIG_SYS_FLASH_BANKS_SIZES
--
2.25.1
[PATCH 5/6] Remove unused CONFIG_CONS_NONE
Remove the latest reference of CONFIG_CONS_NONE in code
Signed-off-by: Patrick Delaunay
---
include/configs/MPC8560ADS.h | 1 -
scripts/config_whitelist.txt | 1 -
2 files changed, 2 deletions(-)
diff --git a/include/configs/MPC8560ADS.h b/include/configs/MPC8560ADS.h
index 3a9ea03292..dcd538fdf1 100644
--- a/include/configs/MPC8560ADS.h
+++ b/include/configs/MPC8560ADS.h
@@ -191,7 +191,6 @@
/* Serial Port */
#define CONFIG_CONS_ON_SCC /* define if console on SCC */
-#undef CONFIG_CONS_NONE /* define if console on something else */
#define CONFIG_SYS_BAUDRATE_TABLE \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400,115200}
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index fe618ff39a..b3ebd20c57 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -149,7 +149,6 @@ CONFIG_COMMON_BOOT
CONFIG_COMPAT
CONFIG_CONS_EXTC_PINSEL
CONFIG_CONS_EXTC_RATE
-CONFIG_CONS_NONE
CONFIG_CONS_ON_SCC
CONFIG_CONS_SCIF0
CONFIG_CONS_SCIF1
--
2.25.1
[PATCH 6/6] scripts: remove CONFIG_IS_ENABLED in config_whitelist.txt
Redefine the macro CONFIG_IS_ENABLED is not allowed, so this entry can be removed in whitelist file. Signed-off-by: Patrick Delaunay --- scripts/config_whitelist.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b3ebd20c57..41a0952c97 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -649,7 +649,6 @@ CONFIG_IRAM_SIZE CONFIG_IRAM_STACK CONFIG_IRAM_TOP CONFIG_IRDA_BASE -CONFIG_IS_ENABLED CONFIG_JFFS2_DEV CONFIG_JFFS2_LZO CONFIG_JFFS2_NAND -- 2.25.1
[PATCH 2/6] am33x: Remove unused define CONFIG_MUSB_HOST
This define was left over from a previous revision, and was never used. Signed-off-by: Patrick Delaunay --- include/configs/am335x_sl50.h | 7 --- scripts/config_whitelist.txt | 1 - 2 files changed, 8 deletions(-) diff --git a/include/configs/am335x_sl50.h b/include/configs/am335x_sl50.h index dff946801c..7fbf421149 100644 --- a/include/configs/am335x_sl50.h +++ b/include/configs/am335x_sl50.h @@ -62,13 +62,6 @@ /* Bootcount using the RTC block */ #define CONFIG_SYS_BOOTCOUNT_BE -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_USB_ETHER) -/* Remove other SPL modes. */ -/* disable host part of MUSB in SPL */ -#undef CONFIG_MUSB_HOST -/* disable EFI partitions and partition UUID support */ -#endif - /* Network. */ #endif /* ! __CONFIG_AM335X_SL50_H */ diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index ca043b2f26..b125568a26 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -857,7 +857,6 @@ CONFIG_MTD_UBI_DEBUG_PARANOID CONFIG_MTD_UBI_GLUEBI CONFIG_MTD_UBI_MODULE CONFIG_MULTI_CS -CONFIG_MUSB_HOST CONFIG_MVGBE_PORTS CONFIG_MVMFP_V2 CONFIG_MVS -- 2.25.1
Re: EXT: Re: [PATCH] configs: Move some usb config in defconfig
On Mon, Oct 04, 2021 at 11:33:45AM +0200, Mark Kettenis wrote:
>
> > From: Patrick Delaunay
> > Date: Mon, 4 Oct 2021 11:23:41 +0200
> >
> > Using the tools moveconfig.py to move the following config in the
> > defconfig files:
> > CONFIG_USB_HOST_ETHER
> > CONFIG_USB_ETHER_ASIX
> > CONFIG_USB_ETHER_MCS7830
> > CONFIG_USB_ETHER_SMSC95XX
> >
> > These option are already migrated since the commit f58ad98a621c ("usb: net:
> > migrate USB Ethernet adapters to Kconfig") and the commit ae3584498bf8
> > ("usb: net: migrate CONFIG_USB_HOST_ETHER to Kconfig").
> >
> > Signed-off-by: Patrick Delaunay
> > ---
> >
> > configs/dh_imx6_defconfig | 2 ++
> > configs/kp_imx6q_tpc_defconfig | 2 ++
> > configs/mx53ppd_defconfig | 4
> > configs/stih410-b2260_defconfig | 4
> > include/configs/dh_imx6.h | 2 --
> > include/configs/kp_imx6q_tpc.h | 2 --
> > include/configs/mx53ppd.h | 4
> > include/configs/stih410-b2260.h | 5 -
> > 8 files changed, 12 insertions(+), 13 deletions(-)
>
> Reviewed-by: Mark Kettenis
>
Reviewed-by: Ian Ray
Re: [PATCH] configs: Move some usb config in defconfig
> From: Patrick Delaunay
> Date: Mon, 4 Oct 2021 11:23:41 +0200
>
> Using the tools moveconfig.py to move the following config in the
> defconfig files:
> CONFIG_USB_HOST_ETHER
> CONFIG_USB_ETHER_ASIX
> CONFIG_USB_ETHER_MCS7830
> CONFIG_USB_ETHER_SMSC95XX
>
> These option are already migrated since the commit f58ad98a621c ("usb: net:
> migrate USB Ethernet adapters to Kconfig") and the commit ae3584498bf8
> ("usb: net: migrate CONFIG_USB_HOST_ETHER to Kconfig").
>
> Signed-off-by: Patrick Delaunay
> ---
>
> configs/dh_imx6_defconfig | 2 ++
> configs/kp_imx6q_tpc_defconfig | 2 ++
> configs/mx53ppd_defconfig | 4
> configs/stih410-b2260_defconfig | 4
> include/configs/dh_imx6.h | 2 --
> include/configs/kp_imx6q_tpc.h | 2 --
> include/configs/mx53ppd.h | 4
> include/configs/stih410-b2260.h | 5 -
> 8 files changed, 12 insertions(+), 13 deletions(-)
Reviewed-by: Mark Kettenis
[PATCH v2] nvme: invalidate correct memory range after read
The current code invalidates the range after the read buffer since the
buffer pointer gets incremented in the read loop. Use a temporary
pointer to make sure we have a pristine pointer to invalidate the
correct memory range after read.
Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
Reviewed-by: Andre Przywara
Signed-off-by: Stefan Agner
---
Changes in v2:
- Use uintptr_t to avoid casts
drivers/nvme/nvme.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index f6465ea7f4..3c529a2fce 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
u64 prp2;
u64 total_len = blkcnt << desc->log2blksz;
u64 temp_len = total_len;
+ uintptr_t temp_buffer = (uintptr_t)buffer;
u64 slba = blknr;
u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
@@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
}
if (nvme_setup_prps(dev, &prp2,
- lbas << ns->lba_shift, (ulong)buffer))
+ lbas << ns->lba_shift, temp_buffer))
return -EIO;
c.rw.slba = cpu_to_le64(slba);
slba += lbas;
c.rw.length = cpu_to_le16(lbas - 1);
- c.rw.prp1 = cpu_to_le64((ulong)buffer);
+ c.rw.prp1 = cpu_to_le64(temp_buffer);
c.rw.prp2 = cpu_to_le64(prp2);
status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
&c, NULL, IO_TIMEOUT);
if (status)
break;
temp_len -= (u32)lbas << ns->lba_shift;
- buffer += lbas << ns->lba_shift;
+ temp_buffer += lbas << ns->lba_shift;
}
if (read)
--
2.33.0
[PATCH] configs: Move some usb config in defconfig
Using the tools moveconfig.py to move the following config in the
defconfig files:
CONFIG_USB_HOST_ETHER
CONFIG_USB_ETHER_ASIX
CONFIG_USB_ETHER_MCS7830
CONFIG_USB_ETHER_SMSC95XX
These option are already migrated since the commit f58ad98a621c ("usb: net:
migrate USB Ethernet adapters to Kconfig") and the commit ae3584498bf8
("usb: net: migrate CONFIG_USB_HOST_ETHER to Kconfig").
Signed-off-by: Patrick Delaunay
---
configs/dh_imx6_defconfig | 2 ++
configs/kp_imx6q_tpc_defconfig | 2 ++
configs/mx53ppd_defconfig | 4
configs/stih410-b2260_defconfig | 4
include/configs/dh_imx6.h | 2 --
include/configs/kp_imx6q_tpc.h | 2 --
include/configs/mx53ppd.h | 4
include/configs/stih410-b2260.h | 5 -
8 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index eb588b68d3..abbb6412e8 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -97,6 +97,8 @@ CONFIG_MXC_SPI=y
CONFIG_SYSRESET=y
CONFIG_SYSRESET_WATCHDOG=y
CONFIG_USB=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="dh"
CONFIG_USB_GADGET_VENDOR_NUM=0x0525
diff --git a/configs/kp_imx6q_tpc_defconfig b/configs/kp_imx6q_tpc_defconfig
index 85fdfad834..bcaa82ab89 100644
--- a/configs/kp_imx6q_tpc_defconfig
+++ b/configs/kp_imx6q_tpc_defconfig
@@ -76,5 +76,7 @@ CONFIG_SYSRESET_WATCHDOG=y
CONFIG_IMX_THERMAL=y
CONFIG_USB=y
# CONFIG_SPL_DM_USB is not set
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
CONFIG_WATCHDOG_TIMEOUT_MSECS=6
CONFIG_IMX_WATCHDOG=y
diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig
index 081707f27e..5f39df85ef 100644
--- a/configs/mx53ppd_defconfig
+++ b/configs/mx53ppd_defconfig
@@ -70,6 +70,10 @@ CONFIG_SYSRESET=y
CONFIG_SYSRESET_WATCHDOG=y
CONFIG_USB=y
CONFIG_USB_EHCI_MX5=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_SMSC95XX=y
CONFIG_DM_VIDEO=y
CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_VIDEO_IPUV3=y
diff --git a/configs/stih410-b2260_defconfig b/configs/stih410-b2260_defconfig
index d5ec00e1e0..a7ad277066 100644
--- a/configs/stih410-b2260_defconfig
+++ b/configs/stih410-b2260_defconfig
@@ -53,6 +53,10 @@ CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_GENERIC=y
CONFIG_USB_DWC3=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_SMSC95XX=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
CONFIG_USB_GADGET_VENDOR_NUM=0x483
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index 7af8fceb71..ee56eb691a 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -50,8 +50,6 @@
/* USB Configs */
#ifdef CONFIG_CMD_USB
#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#define CONFIG_USB_HOST_ETHER
-#define CONFIG_USB_ETHER_ASIX
#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
#define CONFIG_MXC_USB_FLAGS 0
#define CONFIG_USB_MAX_CONTROLLER_COUNT2 /* Enabled USB controller
number */
diff --git a/include/configs/kp_imx6q_tpc.h b/include/configs/kp_imx6q_tpc.h
index 8471dffe83..3061c96e76 100644
--- a/include/configs/kp_imx6q_tpc.h
+++ b/include/configs/kp_imx6q_tpc.h
@@ -23,8 +23,6 @@
/* USB Configs */
#ifdef CONFIG_CMD_USB
#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
-#define CONFIG_USB_HOST_ETHER
-#define CONFIG_USB_ETHER_ASIX
#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
#define CONFIG_MXC_USB_FLAGS 0
#define CONFIG_USB_MAX_CONTROLLER_COUNT2 /* Enabled USB controller
number */
diff --git a/include/configs/mx53ppd.h b/include/configs/mx53ppd.h
index b623242256..f8118818b0 100644
--- a/include/configs/mx53ppd.h
+++ b/include/configs/mx53ppd.h
@@ -14,10 +14,6 @@
#define CONFIG_SYS_FSL_CLK
/* USB Configs */
-#define CONFIG_USB_HOST_ETHER
-#define CONFIG_USB_ETHER_ASIX
-#define CONFIG_USB_ETHER_MCS7830
-#define CONFIG_USB_ETHER_SMSC95XX
#define CONFIG_MXC_USB_PORT1
#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
#define CONFIG_MXC_USB_FLAGS 0
diff --git a/include/configs/stih410-b2260.h b/include/configs/stih410-b2260.h
index b1917c9d3f..2fe0900e9f 100644
--- a/include/configs/stih410-b2260.h
+++ b/include/configs/stih410-b2260.h
@@ -57,11 +57,6 @@
#define CONFIG_USB_OHCI_NEW
#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2
-#define CONFIG_USB_HOST_ETHER
-#define CONFIG_USB_ETHER_ASIX
-#define CONFIG_USB_ETHER_MCS7830
-#define CONFIG_USB_ETHER_SMSC95XX
-
/* NET Configs */
#endif /* __CONFIG_H */
--
2.25.1
Re: [PATCH] nvme: invalidate correct memory range after read
On 2021-09-30 18:09, Andre Przywara wrote:
> On Tue, 28 Sep 2021 10:01:40 +0200
> Stefan Agner wrote:
>
>> The current code invalidates the range after the read buffer since the
>> buffer pointer gets incremented in the read loop. Use a temporary
>> pointer to make sure we have a pristine pointer to invalidate the
>> correct memory range after read.
>
> Ah, good catch!
It did actually create issues in real world where sometimes it would
just not recognize a file system properly when using the ls command.
> This looks good, just one nit below:
>
>> Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
>> Signed-off-by: Stefan Agner
>> ---
>>
>> drivers/nvme/nvme.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
>> index f6465ea7f4..354513ad30 100644
>> --- a/drivers/nvme/nvme.c
>> +++ b/drivers/nvme/nvme.c
>> @@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
>> blknr,
>> u64 prp2;
>> u64 total_len = blkcnt << desc->log2blksz;
>> u64 temp_len = total_len;
>> +void *temp_buffer = buffer;
>
> You could make this an unsigned long (or better uintptr_t), then lose all
> the casts below and avoid the void ptr arithmetic.
Ok, I'll send an update shortly.
>
> But it works either way, so:
>
> Reviewed-by: Andre Przywara
Thanks for your review.
--
Stefan
>
> Cheers,
> Andre
>
>
>>
>> u64 slba = blknr;
>> u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
>> @@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev,
>> lbaint_t blknr,
>> }
>>
>> if (nvme_setup_prps(dev, &prp2,
>> -lbas << ns->lba_shift, (ulong)buffer))
>> +lbas << ns->lba_shift, (ulong)temp_buffer))
>> return -EIO;
>> c.rw.slba = cpu_to_le64(slba);
>> slba += lbas;
>> c.rw.length = cpu_to_le16(lbas - 1);
>> -c.rw.prp1 = cpu_to_le64((ulong)buffer);
>> +c.rw.prp1 = cpu_to_le64((ulong)temp_buffer);
>> c.rw.prp2 = cpu_to_le64(prp2);
>> status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
>> &c, NULL, IO_TIMEOUT);
>> if (status)
>> break;
>> temp_len -= (u32)lbas << ns->lba_shift;
>> -buffer += lbas << ns->lba_shift;
>> +temp_buffer += lbas << ns->lba_shift;
>> }
>>
>> if (read)
[PATCH] Convert CONFIG_STM32_FLASH to Kconfig
This converts the CONFIG_STM32_FLASH to Kconfig by using tools/moveconfig.py Signed-off-by: Patrick Delaunay --- configs/stm32f429-discovery_defconfig | 1 + configs/stm32f429-evaluation_defconfig | 1 + configs/stm32f469-discovery_defconfig | 1 + configs/stm32f746-disco_defconfig | 1 + configs/stm32f769-disco_defconfig | 1 + drivers/mtd/Kconfig| 7 +++ include/configs/stm32f429-discovery.h | 2 -- include/configs/stm32f429-evaluation.h | 2 -- include/configs/stm32f469-discovery.h | 2 -- include/configs/stm32f746-disco.h | 2 -- scripts/config_whitelist.txt | 1 - 11 files changed, 12 insertions(+), 9 deletions(-) diff --git a/configs/stm32f429-discovery_defconfig b/configs/stm32f429-discovery_defconfig index b6388cf00a..ed96c370d5 100644 --- a/configs/stm32f429-discovery_defconfig +++ b/configs/stm32f429-discovery_defconfig @@ -28,3 +28,4 @@ CONFIG_ENV_ADDR=0x804 # CONFIG_NET is not set # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y +CONFIG_STM32_FLASH=y diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig index a75c269d9b..9cbd56c41e 100644 --- a/configs/stm32f429-evaluation_defconfig +++ b/configs/stm32f429-evaluation_defconfig @@ -28,3 +28,4 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y # CONFIG_NET is not set CONFIG_ARM_PL180_MMCI=y CONFIG_MTD_NOR_FLASH=y +CONFIG_STM32_FLASH=y diff --git a/configs/stm32f469-discovery_defconfig b/configs/stm32f469-discovery_defconfig index ecca110850..85639e2a48 100644 --- a/configs/stm32f469-discovery_defconfig +++ b/configs/stm32f469-discovery_defconfig @@ -30,6 +30,7 @@ CONFIG_ARM_PL180_MMCI=y CONFIG_MTD=y CONFIG_DM_MTD=y CONFIG_MTD_NOR_FLASH=y +CONFIG_STM32_FLASH=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_PINCTRL_FULL is not set diff --git a/configs/stm32f746-disco_defconfig b/configs/stm32f746-disco_defconfig index 2694a32f7d..e5e7ef798c 100644 --- a/configs/stm32f746-disco_defconfig +++ b/configs/stm32f746-disco_defconfig @@ -45,6 +45,7 @@ CONFIG_ARM_PL180_MMCI=y CONFIG_MTD=y CONFIG_DM_MTD=y CONFIG_MTD_NOR_FLASH=y +CONFIG_STM32_FLASH=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/stm32f769-disco_defconfig b/configs/stm32f769-disco_defconfig index 10af638840..bb122d691d 100644 --- a/configs/stm32f769-disco_defconfig +++ b/configs/stm32f769-disco_defconfig @@ -44,6 +44,7 @@ CONFIG_ARM_PL180_MMCI=y CONFIG_MTD=y CONFIG_DM_MTD=y CONFIG_MTD_NOR_FLASH=y +CONFIG_STM32_FLASH=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index b303fabe0f..ed69ea114e 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -109,6 +109,13 @@ config HBMC_AM654 This is the driver for HyperBus controller on TI's AM65x and other SoCs +config STM32_FLASH + bool "STM32 MCU Flash driver" + depends on ARCH_STM32 + help +This is the driver of embedded flash for some STMicroelectronics +STM32 MCU. + source "drivers/mtd/nand/Kconfig" source "drivers/mtd/spi/Kconfig" diff --git a/include/configs/stm32f429-discovery.h b/include/configs/stm32f429-discovery.h index 525a5277d8..ef9525574d 100644 --- a/include/configs/stm32f429-discovery.h +++ b/include/configs/stm32f429-discovery.h @@ -21,8 +21,6 @@ #define CONFIG_RED_LED 110 #define CONFIG_GREEN_LED 109 -#define CONFIG_STM32_FLASH - #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ #define CONFIG_SYS_CBSIZE 1024 diff --git a/include/configs/stm32f429-evaluation.h b/include/configs/stm32f429-evaluation.h index 609b4c2c3b..c490e2d98b 100644 --- a/include/configs/stm32f429-evaluation.h +++ b/include/configs/stm32f429-evaluation.h @@ -23,8 +23,6 @@ #define CONFIG_SYS_MAX_FLASH_SECT 12 #define CONFIG_SYS_MAX_FLASH_BANKS 2 -#define CONFIG_STM32_FLASH - #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ #define CONFIG_SYS_CBSIZE 1024 diff --git a/include/configs/stm32f469-discovery.h b/include/configs/stm32f469-discovery.h index a8f6fbf9cf..246dc1f9c6 100644 --- a/include/configs/stm32f469-discovery.h +++ b/include/configs/stm32f469-discovery.h @@ -23,8 +23,6 @@ #define CONFIG_SYS_MAX_FLASH_SECT 12 #define CONFIG_SYS_MAX_FLASH_BANKS 2 -#define CONFIG_STM32_FLASH - #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ #define CONFIG_SYS_CBSIZE 1024 diff --git a/include/configs/stm32f746-disco.h b/include/configs/stm32f746-disco.h index c76d290a57..493699e950 100644 --- a/include/configs/stm32f746-disco.h +++ b/include/configs/stm32f746-disco.h @@ -22,8 +22,6 @@ #define CONFIG_SYS_MAX_FLASH_SECT 8 #define CONFIG_SYS_MAX_FLASH_BANKS 1 -#define CONFIG_STM32_FLASH - #define CONFIG_DW_GMAC_DEFAULT_DMA_PBL (8) #define CONFIG_D
Re: [PATCH] arm: mvebu: Select SPL_SKIP_LOWLEVEL_INIT on ARMADA_32BIT
On Sunday 03 October 2021 11:53:45 Stefan Roese wrote:
> Select SPL_SKIP_LOWLEVEL_INIT on 32bit Armada platforms via Kconfig,
> as this was removed from mach/config.h in a2ac2b96 ("Convert
> CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig").
>
> Signed-off-by: Stefan Roese
> Fixes: a2ac2b96 ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig")
> Cc: Tom Rini
> Cc: Marek Behún
> Cc: Pali Rohár
A385 is working fine with and also without this patch on next branch
(commit e17cbdd050f7127737988997f4a01583b34f7c96)
Tested-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 087643725e85..54dff9986b41 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -11,6 +11,7 @@ config ARMADA_32BIT
> select SPL_DM if SPL
> select SPL_DM_SEQ_ALIAS if SPL
> select SPL_OF_CONTROL if SPL
> + select SPL_SKIP_LOWLEVEL_INIT
> select SPL_SIMPLE_BUS if SPL
> select SUPPORT_SPL
> select TRANSLATION_OFFSET
> --
> 2.33.0
>
Re: [PATCH v8 3/5] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
On 03.10.21 20:40, Tom Rini wrote:
> On Sat, Sep 18, 2021 at 08:17:54AM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> Add the DT entry for a watchdog based on RTI1. It requires additional
>> firmware on the MCU R5F cores to handle the expiry, e.g.
>> https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
>> the power domain to protect it against premature shutdown, mark it
>> shared.
>>
>> Aligns us to the kernel's DT in this regard.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> arch/arm/dts/k3-am65-mcu.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
>> index 7454c8cec0..903796bf7d 100644
>> --- a/arch/arm/dts/k3-am65-mcu.dtsi
>> +++ b/arch/arm/dts/k3-am65-mcu.dtsi
>> @@ -308,4 +308,13 @@
>> ti,loczrama = <1>;
>> };
>> };
>> +
>> +mcu_rti1: rti@4061 {
>> +compatible = "ti,j7-rti-wdt";
>> +reg = <0x0 0x4061 0x0 0x100>;
>> +clocks = <&k3_clks 135 0>;
>> +power-domains = <&k3_pds 135 TI_SCI_PD_SHARED>;
>> +assigned-clocks = <&k3_clks 135 0>;
>> +assigned-clock-parents = <&k3_clks 135 4>;
>> +};
>> };
>
> So, in applying
> https://patchwork.ozlabs.org/project/uboot/patch/20210910213743.30793-1-tr...@konsulko.com/
> to bring us fully to v5.14 for K3 platforms, this patch is no longer
> needed, and I'm deferring it. The only difference is the node name is
> "watchdog@4061" not "rti@4061" but should not matter (and
> doesn't look to from a quick read of the rest of the series.
>
Ack, this is now obsolete.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v5 3/5] env: Allow U-Boot scripts to be placed in a .env file
On 02/10/2021 02.38, Simon Glass wrote: > At present U-Boot environment variables, and thus scripts, are defined > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text > to this file and dealing with quoting and newlines is harder than it > should be. It would be better if we could just type the script into a > text file and have it included by U-Boot. Indeed, the pain of CONFIG_EXTRA_ENV_SETTINGS was part of the motivation for introducing CONFIG_USE_DEFAULT_ENV_FILE. > Add a feature that brings in a .env file associated with the board > config, if present. To use it, create a file in a board//env > directory called .env (or common.env if you want the same > environment for all boards). > > The environment variables should be of the form "var=value". Values can > extend to multiple lines. See the README under 'Environment Variables:' > for more information and an example. > > Comments are not permitted in the environment with this commit. Perhaps some remarks on how this compares/relates to CONFIG_USE_DEFAULT_ENV_FILE and CONFIG_ENV_IMPORT_FDT would be in order? In particular, the latter seems like it could already do the "amend the environent per vendor/board" with appropriate settings in the -u-boot.dtsi files? I don't think either of those currently support using CONFIG_ variables in the definitions, but perhaps that could be fixed. I don't have anything against these patches as such, I'd just like to understand precisely what they bring that cannot already be done with existing mechanisms. Rasmus
