[U-Boot] [Patch v2] armv8: Secure Boot: Modify boot_a_script definition
From: Vinitha V Pillai
boot_script_hdr does not exist, it should not continue to
boot. So adding separate validation after loading boot_script.
The secure boot validation of the bootscript header will fail
and halts the further execution of commands which prevent
source command from execution.
Signed-off-by: Vinitha V Pillai
Signed-off-by: Udit Agarwal
---
Changes in V2:
Corrects commit message to add more clarity.
include/configs/ls1012afrwy.h| 3 ++-
include/configs/ls1012ardb.h | 3 ++-
include/configs/ls1021atwr.h | 3 ++-
include/configs/ls1043a_common.h | 3 ++-
include/configs/ls1046a_common.h | 5 +++--
include/configs/ls1088ardb.h | 3 ++-
include/configs/ls2080ardb.h | 3 ++-
7 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h
index ebb1df41c7..12e6437a05 100644
--- a/include/configs/ls1012afrwy.h
+++ b/include/configs/ls1012afrwy.h
@@ -98,7 +98,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+ "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+ "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0" \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index f149a604cf..f6640fa499 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -98,7 +98,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+ "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+ "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0" \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index da55bf2f43..2616f4aa5c 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -364,7 +364,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+ "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+ "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0" \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 2e9d476483..8618a5f182 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -275,7 +275,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+ "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+ "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"\
"qspi_bootcmd=echo Trying load from qspi..;"\
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 24ff2d1547..e4e71b24d4 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -256,8 +256,9 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
- "&& esbc_validate ${scripthdraddr};"\
+ "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+ "env exists secureboot "\
+ "&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0" \
"qspi_bootcmd=echo Trying load from qspi..;" \
"sf probe && sf read $load_addr " \
diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
index 45af087dc6..322adb530a 100644
--- a/include/configs/ls1088ardb.h
+++
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 08:10:31AM +, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > >
> > > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > > >
> > > > >
> > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel
> > > > > .com
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > Currently u-boot only support standard PSCI functions for
> > > > > > power
> > > > > > management
> > > > > > and lack of convenient method to allow the users to extend
> > > > > > the
> > > > > > PSCI
> > > > > > functions
> > > > > > to support platform specific services. Most of the u-boot
> > > > > > users
> > > > > > still rely
> > > > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > > > management and
> > > > > > platform specific PSCI services.
> > > > > > The purpose of this patchsets is to allow u-boot users to
> > > > > > support
> > > > > > their
> > > > > > own platform specific secure SMC/PSCI services without
> > > > > > making
> > > > > > any
> > > > > > SMC calls to ATF. This will benefit the users who need to
> > > > > > use
> > > > > > u-
> > > > > > boot as the
> > > > > > only bootloader and secure service provider without relying
> > > > > > on
> > > > > > ATF.
> > > > > >
> > > > > > Below is a simple code example for adding your own PSCI
> > > > > > functions:
> > > > > >
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > #define PSCI_SMC64_FUNC_ID1 0xC201
> > > > > > #define PSCI_SMC64_FUNC_ID2 0xC202
> > > > > >
> > > > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 1 */
> > > > > > }
> > > > > >
> > > > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 2 */
> > > > > > }
> > > > > >
> > > > > > DECLARE_SECURE_SVC(plat_specific_func1,
> > > > > > PSCI_SMC64_FUNC_ID1,
> > > > > > psci_plat_specific_func1);
> > > > > > DECLARE_SECURE_SVC(plat_specific_func2,
> > > > > > PSCI_SMC64_FUNC_ID2,
> > > > > > psci_plat_specific_func2);
> > > > > >
> > > > > > Ang, Chee Hong (1):
> > > > > > ARMv8: Disable fwcall when PSCI is enabled
> > > > > >
> > > > > > Chee Hong Ang (1):
> > > > > > ARMv8: Allow SiP service extensions on top of PSCI code
> > > > > Conceptually, I suppose this is a logical step. In
> > > > > specifics,
> > > > > would
> > > > > we
> > > > > want to make this functionality opt-in, or no, that doesn't
> > > > > make
> > > > > sense?
> > > > >
> > > > Allowing user to add platform specific service is part of
> > > > SMC/PSCI
> > > > specification as specifed in ARM document (Table 2-1):
> > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_D
> > > > EN00
> > > > 28B_
> > > > SMC_Calling_Convention.pdf
> > > >
> > > > So I think this functionality should be part of the standard
> > > > PSCI/SMC
> > > > implementation. Currently u-boot only support standard PSCI
> > > > call
> > > > which
> > > > is:
> > > > --
> > > > >
> > > > >
> > > > > 0x8400-0x841F | PSCI 32-bit calls |
> > > > > 0xC400-0xC41F | PSCI 64-bit calls |
> > > > --
> > > >
> > > > My implementation do not affect or alter the behavior of any
> > > > existing
> > > > standard PSCI calls.
> > > >
> > > > Users can simply add their own platform specific services by
> > > > using
> > > > the
> > > > service call range as below:
> > > >
> > > > >
> > > > >
> > > > > 0xC200-0xC200 | SMC64: SiP Service Calls |
> > > > > 0xC300-0xC300 | SMC64: OEM Service Calls |
> > > >
> > > >
> > > > For complete service call ranges please refer to Table 6-2 in
> > > > the
> > > > ARM
> > > > document.
> > > OK, thanks!
> > >
> > Any chance this enhancement get accepted ? Thanks.
> After the current release, if there's no further comments.
>
Hi Tom,
Is this patch being merged into mainline ? Or you have any further
concern or comments ? Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: Add workaround for USB erratum A-050106
USB3.0 Receiver needs to enable fixed equalization
for each of PHY instances in an SOC. This is similar
to erratum A-009007, but this one is for LX2160A,
and the register value is different.
Signed-off-by: Ran Wang
---
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 13 -
.../include/asm/arch-fsl-layerscape/immap_lsch3.h | 5 +
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f48481f465..f99b9d1a7a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -191,6 +191,7 @@ config ARCH_LX2160A
select SYS_FSL_DDR_VER_50
select SYS_FSL_EC1
select SYS_FSL_EC2
+ select SYS_FSL_ERRATUM_A050106
select SYS_FSL_HAS_RGMII
select SYS_FSL_HAS_SEC
select SYS_FSL_HAS_CCN508
@@ -335,6 +336,9 @@ config SYS_FSL_ERRATUM_A009008
config SYS_FSL_ERRATUM_A009798
bool "Workaround for USB PHY erratum A009798"
+config SYS_FSL_ERRATUM_A050106
+ bool "Workaround for USB PHY erratum A050106"
+
config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 06f3edb302..040d74dab5 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -139,7 +139,8 @@ static void erratum_a008997(void)
out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_3);
\
out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_4)
-#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
+#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) || \
+ defined(CONFIG_ARCH_LX2160A)
#define PROGRAM_USB_PHY_RX_OVRD_IN_HI(phy) \
out_le16((phy) + DCSR_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_1); \
@@ -171,6 +172,15 @@ static void erratum_a009007(void)
#endif /* CONFIG_SYS_FSL_ERRATUM_A009007 */
}
+static void erratum_a050106(void)
+{
+#if defined(CONFIG_ARCH_LX2160A)
+ void __iomem *dcsr = (void __iomem *)DCSR_BASE;
+
+ PROGRAM_USB_PHY_RX_OVRD_IN_HI(dcsr + DCSR_USB_PHY1);
+ PROGRAM_USB_PHY_RX_OVRD_IN_HI(dcsr + DCSR_USB_PHY2);
+#endif
+}
#if defined(CONFIG_FSL_LSCH3)
/*
* This erratum requires setting a value to eddrtqcr1 to
@@ -323,6 +333,7 @@ void fsl_lsch3_early_init_f(void)
erratum_a009798();
erratum_a008997();
erratum_a009007();
+ erratum_a050106();
#ifdef CONFIG_CHAIN_OF_TRUST
/* In case of Secure Boot, the IBR configures the SMMU
* to allow only Secure transactions.
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 9fab88ab2f..572765628a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -209,8 +209,13 @@
#define DCSR_USB_PHY_RX_OVRD_IN_HI 0x200C
#define USB_PHY_RX_EQ_VAL_10x
#define USB_PHY_RX_EQ_VAL_20x0080
+#if defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
#define USB_PHY_RX_EQ_VAL_30x0380
#define USB_PHY_RX_EQ_VAL_40x0b80
+#elif defined(CONFIG_ARCH_LX2160A)
+#define USB_PHY_RX_EQ_VAL_30x0080
+#define USB_PHY_RX_EQ_VAL_40x0880
+#endif
#define TP_ITYP_AV 0x0001 /* Initiator available */
#define TP_ITYP_TYPE(x)(((x) & 0x6) >> 1) /* Initiator Type */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: add overall SPL size check
On Mon, Apr 22, 2019 at 11:10 PM Tom Rini wrote: > > On Mon, Apr 22, 2019 at 10:27:21PM +0200, Simon Goldschmidt wrote: > > This adds a size check for SPL that can dynamically check generated > > SPL binaries (including devicetree) for a size limit that ensures > > this image plus global data, heap and stack fit in initial SRAM. > > > > Since some of these sizes are not available to make, a new host tool > > 'spl_size_limit' is added that dumps the resulting maximum size for > > an SPL binary to stdout. This tool is used in toplevel Makefile to > > implement the size check on SPL binaries. > > > > Signed-off-by: Simon Goldschmidt > > --- > > > > Changes in v2: > > - added missing tools/spl_size_limit.c > > > > Kconfig| 8 > > Makefile | 2 +- > > common/spl/Kconfig | 36 > > tools/Makefile | 2 ++ > > tools/spl_size_limit.c | 30 ++ > > Ah, now I get it, and why you said you depend on Heinrich's series now, > OK. This isn't quite what I envisioned, but, maybe that's OK. I was > thinking we could drop the whole of the shell function, stat() the file > and return 0/error. But I guess on the whole we've got the shell > function portable and not too fragile looking, so maybe it's not worth > the extra work there. I also thought in your direction first. But then I figured with the current way of doing the size check, showing the current vs. maximum would be easier. If the Makefile didn't know the size, the new tool would have to print it to show the difference... > I do have one problem I'd like to discuss, which is that to replicate > this for a TPL size limit (which we totally have and need to deal with), > we cp and sed spl_size_limit.c to tpl_size_limit.c. > > I don't however see a clever way to avoid that. CONFIG_IS_ENABLED() > would let us have the same #if test, but doing > size_limit -= CONFIG_SPL_FOO CONFIG_TPL_FOO; > is probably getting too clever. Hmm, let me think about that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] riscv: prior_stage_fdt_address only be used when OF_PRIOR_STAGE is enable
From: Rick Chen This patch will fix prior_stage_fdt_address write failure problem, when AE350 was booting from flash. When AE350 was booting from falsh, prior_stage_fdt_address will be in flash address, we shall avoid it to be written. Signed-off-by: Rick Chen Cc: Greentime Hu --- arch/riscv/cpu/start.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index d030d4a..0e672e0 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -111,7 +111,9 @@ call_board_init_f_0: bneztp, secondary_hart_loop #endif +# if CONFIG_IS_ENABLED(OF_PRIOR_STAGE) la t0, prior_stage_fdt_address +#endif SREGs1, 0(t0) jal board_init_f_init_reserve -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] riscv: configs: AE350 will use OF_PRIOR_STAGE when boot from ram
From: Rick Chen When AE350 was booting from ram, use OF_PRIOR_STAGE instead of OF_PRIOR_STAGE. Signed-off-by: Rick Chen Cc: Greentime Hu --- configs/ae350_rv32_defconfig | 2 +- configs/ae350_rv64_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig index e13c7de..54b65f1 100644 --- a/configs/ae350_rv32_defconfig +++ b/configs/ae350_rv32_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_SF_TEST=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y -CONFIG_OF_BOARD=y +CONFIG_OF_PRIOR_STAGE=y CONFIG_DEFAULT_DEVICE_TREE="ae350_32" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig index a41f918..0ff4de8 100644 --- a/configs/ae350_rv64_defconfig +++ b/configs/ae350_rv64_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y -CONFIG_OF_BOARD=y +CONFIG_OF_PRIOR_STAGE=y CONFIG_DEFAULT_DEVICE_TREE="ae350_64" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] riscv: configs: Support AE350 SMP boot from flash flow
From: Rick Chen Add two defconfig to support AE350 SMP boot from flash by disable CONFIG_HART_LOTTERY and CONFIG_AVAILABLE_HARTS. Signed-off-by: Rick Chen Cc: Greentime Hu --- configs/ae350_rv32_xip_defconfig | 37 + configs/ae350_rv64_xip_defconfig | 38 ++ 2 files changed, 75 insertions(+) create mode 100644 configs/ae350_rv32_xip_defconfig create mode 100644 configs/ae350_rv64_xip_defconfig diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig new file mode 100644 index 000..1639367 --- /dev/null +++ b/configs/ae350_rv32_xip_defconfig @@ -0,0 +1,37 @@ +CONFIG_RISCV=y +CONFIG_HART_LOTTERY=n +CONFIG_AVAILABLE_HARTS=n +CONFIG_SYS_TEXT_BASE=0x8000 +CONFIG_TARGET_AX25_AE350=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SYS_PROMPT="RISC-V # " +CONFIG_CMD_IMLS=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_BOOTP_PREFER_SERVERIP=y +CONFIG_CMD_CACHE=y +CONFIG_OF_BOARD=y +CONFIG_DEFAULT_DEVICE_TREE="ae350_32" +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_MMC=y +CONFIG_FTSDC010=y +CONFIG_FTSDC010_SDIO=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_CFI_FLASH=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_FTMAC100=y +CONFIG_BAUDRATE=38400 +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_ATCSPI200_SPI=y diff --git a/configs/ae350_rv64_xip_defconfig b/configs/ae350_rv64_xip_defconfig new file mode 100644 index 000..d6a502c --- /dev/null +++ b/configs/ae350_rv64_xip_defconfig @@ -0,0 +1,38 @@ +CONFIG_RISCV=y +CONFIG_HART_LOTTERY=n +CONFIG_AVAILABLE_HARTS=n +CONFIG_SYS_TEXT_BASE=0x8000 +CONFIG_TARGET_AX25_AE350=y +CONFIG_ARCH_RV64I=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SYS_PROMPT="RISC-V # " +CONFIG_CMD_IMLS=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_BOOTP_PREFER_SERVERIP=y +CONFIG_CMD_CACHE=y +CONFIG_OF_BOARD=y +CONFIG_DEFAULT_DEVICE_TREE="ae350_64" +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_MMC=y +CONFIG_FTSDC010=y +CONFIG_FTSDC010_SDIO=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_CFI_FLASH=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_FTMAC100=y +CONFIG_BAUDRATE=38400 +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_ATCSPI200_SPI=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable
From: Rick Chen
In smp flow this two features only can be enabled when U-Boot
boot from ram. It shall be disabled when U-Boot boot from flash.
Add CONFIG_HART_LOTTERY and CONFIG_AVAILABLE_HARTS to select
this two features. Their default value will say YES for booting
from ram.
AE350 will encounter the the write failure problem since
hart_lottery and available_harts_lock was not in ram address
but in flash address when booing from flash.
This patch can help to fix the failure problem when AE350 was
booting from flash by disable this two features.
Signed-off-by: Rick Chen
Cc: Greentime Hu
---
arch/riscv/Kconfig | 21 +
arch/riscv/cpu/cpu.c | 4
arch/riscv/cpu/start.S | 9 -
arch/riscv/include/asm/global_data.h | 2 ++
arch/riscv/lib/asm-offsets.c | 2 ++
arch/riscv/lib/smp.c | 2 ++
6 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ae8ff7b..4354396 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -162,6 +162,27 @@ config SBI_IPI
default y if RISCV_SMODE
depends on SMP
+config HART_LOTTERY
+ bool "Hart lottery support"
+ default y
+ depends on SMP
+ help
+ This will upport hart lottery, all harts have changce to become
+ main hart. But if you say N here, hart 0 will be the main hart.
+ It only can be enabled when U-Boot boot from ram, but shall be
+ disabled when boot from flash.
+
+config AVAILABLE_HARTS
+ bool "available harts support"
+ default y
+ depends on SMP
+ depends on HART_LOTTERY
+ help
+ This will help to record active harts and compare with dts' cpus.
+ So it will not send ipi to in-active harts.
+ It only can be enabled when U-Boot boot from ram, but shall be
+ disabled when boot from flash.
+
config STACK_SIZE_SHIFT
int
default 13
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index c32de8a..0add783 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -16,13 +16,17 @@
* before the bss section is available.
*/
phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
+#ifdef CONFIG_HART_LOTTERY
u32 hart_lottery __attribute__((section(".data"))) = 0;
+#endif
+#ifdef CONFIG_AVAILABLE_HARTS
/*
* The main hart running U-Boot has acquired available_harts_lock until it has
* finished initialization of global data.
*/
u32 available_harts_lock = 1;
+#endif
static inline bool supports_extension(char ext)
{
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index a4433fb..d030d4a 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -98,6 +98,7 @@ call_board_init_f_0:
mv sp, a0
#endif
+#ifdef CONFIG_HART_LOTTERY
/*
* Pick hart to initialize global data and run U-Boot. The other harts
* wait for initialization to complete.
@@ -106,6 +107,9 @@ call_board_init_f_0:
li s2, 1
amoswap.w s2, t1, 0(t0)
bnezs2, wait_for_gd_init
+#else
+ bneztp, secondary_hart_loop
+#endif
la t0, prior_stage_fdt_address
SREGs1, 0(t0)
@@ -115,6 +119,7 @@ call_board_init_f_0:
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
+#ifdef CONFIG_AVAILABLE_HARTS
la t0, available_harts_lock
fence rw, w
amoswap.w zero, zero, 0(t0)
@@ -135,13 +140,15 @@ wait_for_gd_init:
fence rw, w
amoswap.w zero, zero, 0(t0)
+#endif
+#ifdef CONFIG_HART_LOTTERY
/*
* Continue on hart lottery winner, others branch to
* secondary_hart_loop.
*/
bnezs2, secondary_hart_loop
-
+#endif
/* Enable cache */
jal icache_enable
jal dcache_enable
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index dffcd45..e2e8b65 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -27,7 +27,9 @@ struct arch_global_data {
#ifdef CONFIG_SMP
struct ipi_data ipi[CONFIG_NR_CPUS];
#endif
+#ifdef CONFIG_AVAILABLE_HARTS
ulong available_harts;
+#endif
};
#include
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index f998402..3ebda97 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,7 +14,9 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+#ifdef CONFIG_AVAILABLE_HARTS
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
+#endif
return 0;
}
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index caa292c..4de7ea2 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -63,9 +63,11 @@ static int send_ipi_many(struct ipi_data *ipi)
[U-Boot] [PATCH 0/4] AE350 support SMP boot from flash
From: Rick Chen In current RISC-V SMP flow, AE350 will encounter the the write failure problem since hart_lottery and available_harts_lock was not in ram address but in flash address when booing from flash. This patch can help to fix the failure problem when AE350 was booting from flash by disable this two features. Rick Chen (4): riscv: hart_lottery and available harts feature can be seletable riscv: configs: Support AE350 SMP boot from flash flow riscv: prior_stage_fdt_address only be used when OF_PRIOR_STAGE is enable riscv: configs: AE350 will use OF_PRIOR_STAGE when boot from ram arch/riscv/Kconfig | 21 arch/riscv/cpu/cpu.c | 4 arch/riscv/cpu/start.S | 11 ++- arch/riscv/include/asm/global_data.h | 2 ++ arch/riscv/lib/asm-offsets.c | 2 ++ arch/riscv/lib/smp.c | 2 ++ configs/ae350_rv32_defconfig | 2 +- configs/ae350_rv32_xip_defconfig | 37 +++ configs/ae350_rv64_defconfig | 2 +- configs/ae350_rv64_xip_defconfig | 38 10 files changed, 118 insertions(+), 3 deletions(-) create mode 100644 configs/ae350_rv32_xip_defconfig create mode 100644 configs/ae350_rv64_xip_defconfig -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: goldsimon/u-boot
On Mon, Apr 22, 2019 at 9:08 PM Marek Vasut wrote: > > On 4/22/19 8:31 PM, Simon Goldschmidt wrote: > > The following changes since commit > > 6c5f8dd540d7a8eff244d4c27a09451ca12c8d20: > > > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-21 > > 19:00:04 -0400) > > > > are available in the Git repository at: > > > > https://github.com/goldsimon/u-boot.git > > > > for you to fetch changes up to 5ff194620a5ada0bf05d9dc2668d2233289742a6: > > > > arm: socfpga: clean up board config files (2019-04-22 20:08:59 +0200) > > Applied, thanks. Sorry, but I have to take that back. I've somehow managed to get a build error for socfpga_vining_fpga. I'll send another one as soon as I have fixed this. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Is mmc still being actively maintained?
Hi Peng, > Hi Lukasz, > > > Subject: Re: [U-Boot] Is mmc still being actively maintained? > > > > Hi Peng, > > > > > Hi All, Jaehoon > > > > > > Is mmc still being actively maintained? > > > > As fair as I can tell, it is "maintained" by Tom and Marek as last > > PR by Jaehoon has been sent on: > > Tue, 8 May 2018 16:22:14 +0900 > > > > > I would help if it is not > > > being maintained. > > > > It would be great if you could help with maintaining this code as a > > dedicated Custodian. > > If no one maintaining this code, I could be a dedicated custodian to > collect patches if no objections. +1 Then just prepare the patch to add yourself as a custodian/maintainer for mmc :-) > > Thanks, > Peng. > > > > > > > > > > > Thanks, > > > Peng. > > > ___ > > > U-Boot mailing list > > > U-Boot@lists.denx.de > > > https://lists.denx.de/listinfo/u-boot > > > > > > > > > > Best regards, > > > > Lukasz Majewski > > > > -- > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > > lu...@denx.de Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgp5TTlCW7_AJ.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] efi_loader: rework bootefi/bootmgr
Okay. Once your pull is done, I will submit "efi variable" patch, which is more experimental than bootefi/bootmgr rework. -Takahiro Akashi On Tue, 23 Apr 2019 at 13:57, Heinrich Schuchardt wrote: > > On 4/23/19 2:24 AM, AKASHI, Takahiro wrote: > > Heinrich, > > > > On Tue, 23 Apr 2019 at 03:16, Heinrich Schuchardt > > wrote: > >> > >> On 4/19/19 5:22 AM, AKASHI Takahiro wrote: > >>> There are several reasons that I want to rework/refactor bootefi command > >>> as well as bootmgr: > >>> * Some previous commits on bootefi.c have made the code complicated > >>>and a bit hard to understand. > >>> > >>> * do_bootefi_exec() would better be implemented using load_image() along > >>>with start_image() to be aligned with UEFI interfaces. > >>> > >>> * Contrary to the other part, efi_selftest part of the code is unusual > >>>in terms of loading/execution path in do_bootefi(). > >>> > >>> * When we will support "secure boot" in the future, EFI Boot Manager > >>>is expected to be invoked as a standalone command without any arguments > >>>to mitigate security surfaces. > >>> > >>> In this patch set, > >>> Patch#1 to #7 are preparatory patches for patch#8. > >>> Patch#8 is a core part of reworking. > >>> Patch#9 is for standalone boot manager. > >> > >> Hello Takahiro, > >> > >> your patches 1-8 are now (with some modifications) in the efi-2019-07 > >> branch. I have added some more patches. > >> > >> https://github.com/xypron2/u-boot/commits/efi-2019-07 > >> > >> Travis CI testing was ok: > >> https://travis-ci.org/xypron2/u-boot/builds/522947698 > >> > >> I have tested on real hardware without error: > >> * TinkerBoard (32 bit) boot via GRUB > >> * Pine64 A64 LTS (64 bit) boot via iPXE and GRUB > >> * Odroid C2 (64 bit) boot via GRUB > >> > >> If you are ok with the adjustments to your patch series I will create a > >> pull request. > > > > Thank you for the merge. > > One question: how did you fix a grub error that you reported before? > > I fixed the issue that iPXE could not find a chained script via > efi_loader: correctly split device path of loaded image > https://lists.denx.de/pipermail/u-boot/2019-April/365907.html > > Furthermore I fixed a bug in Debian's QEMU by applying Alex's > https://github.com/qemu/qemu/commit/2d2a4549cc29850aab891495685a7b31f5254b12 > > Best regards > > Heinrich > > > > > -Takahiro Akashi > > > > > >> Best regards > >> > >> Heinrich > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] efi_loader: rework bootefi/bootmgr
On 4/23/19 2:24 AM, AKASHI, Takahiro wrote: Heinrich, On Tue, 23 Apr 2019 at 03:16, Heinrich Schuchardt wrote: On 4/19/19 5:22 AM, AKASHI Takahiro wrote: There are several reasons that I want to rework/refactor bootefi command as well as bootmgr: * Some previous commits on bootefi.c have made the code complicated and a bit hard to understand. * do_bootefi_exec() would better be implemented using load_image() along with start_image() to be aligned with UEFI interfaces. * Contrary to the other part, efi_selftest part of the code is unusual in terms of loading/execution path in do_bootefi(). * When we will support "secure boot" in the future, EFI Boot Manager is expected to be invoked as a standalone command without any arguments to mitigate security surfaces. In this patch set, Patch#1 to #7 are preparatory patches for patch#8. Patch#8 is a core part of reworking. Patch#9 is for standalone boot manager. Hello Takahiro, your patches 1-8 are now (with some modifications) in the efi-2019-07 branch. I have added some more patches. https://github.com/xypron2/u-boot/commits/efi-2019-07 Travis CI testing was ok: https://travis-ci.org/xypron2/u-boot/builds/522947698 I have tested on real hardware without error: * TinkerBoard (32 bit) boot via GRUB * Pine64 A64 LTS (64 bit) boot via iPXE and GRUB * Odroid C2 (64 bit) boot via GRUB If you are ok with the adjustments to your patch series I will create a pull request. Thank you for the merge. One question: how did you fix a grub error that you reported before? I fixed the issue that iPXE could not find a chained script via efi_loader: correctly split device path of loaded image https://lists.denx.de/pipermail/u-boot/2019-April/365907.html Furthermore I fixed a bug in Debian's QEMU by applying Alex's https://github.com/qemu/qemu/commit/2d2a4549cc29850aab891495685a7b31f5254b12 Best regards Heinrich -Takahiro Akashi Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] net: phy: cortina: Use block layer to read from mmc
From: Yinbo Zhu
This patch is to use block layer to read from mmc in cortina
Signed-off-by: Yinbo Zhu
---
Change in v2:
Update the commit information.
drivers/net/phy/cortina.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/cortina.c
index a04a118f90..2337c3403c 100644
--- a/drivers/net/phy/cortina.c
+++ b/drivers/net/phy/cortina.c
@@ -176,7 +176,7 @@ void cs4340_upload_firmware(struct phy_device *phydev)
printf("MMC read: dev # %u, block # %u, count %u ...\n",
dev, blk, cnt);
mmc_init(mmc);
- (void)mmc->block_dev.block_read(>block_dev, blk, cnt,
+ (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
addr);
}
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
On Mon, Apr 22, 2019 at 9:00 PM Peng Fan wrote: > > Hi Fabio > > > Subject: Booting MX6 via Serial Download after DM conversion > > > > Hi, > > > > Has anyone managed to boot i.MX6 via serial download protocol after the > > conversion to DM? > I 'think' the DM conversion requires the USB Driver to be defined as UCLASS_USB_GADGET_GENERIC in order to be used as a peripheral. I have been following one of the TI boards [1] who's USB Driver has a bind tool that go through the device tree and looks to see if the "dr_mode" entry and then binds the appropriate driver (either HOST or GADGET). I started a conversion on this, so I have a patch I can sent to people, but I haven't gotten the GADGET side working, but I have a binder function that then loads the host driver when "dr_mode" is set to host. I haven't had a lot of time to try and figure out the GADGET side of things yet. If someone wants me to send the a patch for what I have so far, I can do that, but it only supports host mode. I am fairly certain all gadget devices are broken on i.MX6 with DM_USB enabled, so in SPL, I had to disable DM_USB in order to maintain the SDP tool compatibility in SPL. [1] - http://git.denx.de/?p=u-boot.git;a=commitdiff;h=7d98dbcc3dc8f1b93676d0953f3bee0db3796eb0 adam > Include Abel who did the conversion. > > > > > On a mx6sabresd I can no longer boot via SDP running 2019.04: > > > > After running 'sudo ./imx_usb SPL' I get: > > Honestly I am not familiar with imx_usb, we use mfgtool previously and not > uuu tool. > Would you share where to download imx_usb and any doc, > Then we will debug this issue. > > Thanks, > Peng. > > > > > U-Boot SPL 2019.04 (Apr 22 2019 - 19:45:46 -0300) Trying to boot from USB > > SDP > > SDP: initialize... > > SDP: handle requests.. > > > > Then I load the u-boot-dtb.img binary and the following error is seen: > > > > $ sudo ./imx_usb u-boot-dtb.img > > config file > > vid=0x066f pid=0x3780 file_name=mx23_usb_work.conf > > vid=0x15a2 pid=0x004f file_name=mx28_usb_work.conf > > vid=0x15a2 pid=0x0052 file_name=mx50_usb_work.conf > > vid=0x15a2 pid=0x0054 file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x0061 file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x0063 file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x0071 file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x007d file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x0080 file_name=mx6_usb_work.conf > > vid=0x1fc9 pid=0x0128 file_name=mx6_usb_work.conf > > vid=0x15a2 pid=0x0076 file_name=mx7_usb_work.conf > > vid=0x1fc9 pid=0x0126 file_name=mx7ulp_usb_work.conf > > vid=0x15a2 pid=0x0041 file_name=mx51_usb_work.conf > > vid=0x15a2 pid=0x004e file_name=mx53_usb_work.conf > > vid=0x15a2 pid=0x006a file_name=vybrid_usb_work.conf vid=0x066f > > pid=0x37ff file_name=linux_gadget.conf > > vid=0x1b67 pid=0x4fff file_name=mx6_usb_sdp_spl.conf > > vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf > > vid=0x1fc9 pid=0x012b file_name=mx8mq_usb_work.conf config file > > > > parse /usr/etc/imx-loader.d//mx6_usb_sdp_spl.conf > > Trying to open device vid=0x0525 pid=0xb4a4 Interface 0 claimed HAB > > security state: development mode (0x56787856) == work item filename > > u-boot-dtb.img load_size 0 bytes load_addr 0x dcd 1 clear_dcd 0 > > plug 1 jump_mode 3 jump_addr 0x == end work item header not > > found 8400:2e77d044, 4000 do_download failed, err=-22 HAB security state: > > development mode (0x56787856) > > > > With 2019.01 (prior to DM conversion) I can boot via SDP just fine. > > > > Does anyone have any suggestions? > > > > Thanks, > > > > Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
Hi Fabio > Subject: Booting MX6 via Serial Download after DM conversion > > Hi, > > Has anyone managed to boot i.MX6 via serial download protocol after the > conversion to DM? Include Abel who did the conversion. > > On a mx6sabresd I can no longer boot via SDP running 2019.04: > > After running 'sudo ./imx_usb SPL' I get: Honestly I am not familiar with imx_usb, we use mfgtool previously and not uuu tool. Would you share where to download imx_usb and any doc, Then we will debug this issue. Thanks, Peng. > > U-Boot SPL 2019.04 (Apr 22 2019 - 19:45:46 -0300) Trying to boot from USB > SDP > SDP: initialize... > SDP: handle requests.. > > Then I load the u-boot-dtb.img binary and the following error is seen: > > $ sudo ./imx_usb u-boot-dtb.img > config file > vid=0x066f pid=0x3780 file_name=mx23_usb_work.conf > vid=0x15a2 pid=0x004f file_name=mx28_usb_work.conf > vid=0x15a2 pid=0x0052 file_name=mx50_usb_work.conf > vid=0x15a2 pid=0x0054 file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x0061 file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x0063 file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x0071 file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x007d file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x0080 file_name=mx6_usb_work.conf > vid=0x1fc9 pid=0x0128 file_name=mx6_usb_work.conf > vid=0x15a2 pid=0x0076 file_name=mx7_usb_work.conf > vid=0x1fc9 pid=0x0126 file_name=mx7ulp_usb_work.conf > vid=0x15a2 pid=0x0041 file_name=mx51_usb_work.conf > vid=0x15a2 pid=0x004e file_name=mx53_usb_work.conf > vid=0x15a2 pid=0x006a file_name=vybrid_usb_work.conf vid=0x066f > pid=0x37ff file_name=linux_gadget.conf > vid=0x1b67 pid=0x4fff file_name=mx6_usb_sdp_spl.conf > vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf > vid=0x1fc9 pid=0x012b file_name=mx8mq_usb_work.conf config file > > parse /usr/etc/imx-loader.d//mx6_usb_sdp_spl.conf > Trying to open device vid=0x0525 pid=0xb4a4 Interface 0 claimed HAB > security state: development mode (0x56787856) == work item filename > u-boot-dtb.img load_size 0 bytes load_addr 0x dcd 1 clear_dcd 0 > plug 1 jump_mode 3 jump_addr 0x == end work item header not > found 8400:2e77d044, 4000 do_download failed, err=-22 HAB security state: > development mode (0x56787856) > > With 2019.01 (prior to DM conversion) I can boot via SDP just fine. > > Does anyone have any suggestions? > > Thanks, > > Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] efi_loader: rework bootefi/bootmgr
Heinrich, On Tue, 23 Apr 2019 at 03:16, Heinrich Schuchardt wrote: > > On 4/19/19 5:22 AM, AKASHI Takahiro wrote: > > There are several reasons that I want to rework/refactor bootefi command > > as well as bootmgr: > > * Some previous commits on bootefi.c have made the code complicated > > and a bit hard to understand. > > > > * do_bootefi_exec() would better be implemented using load_image() along > > with start_image() to be aligned with UEFI interfaces. > > > > * Contrary to the other part, efi_selftest part of the code is unusual > > in terms of loading/execution path in do_bootefi(). > > > > * When we will support "secure boot" in the future, EFI Boot Manager > > is expected to be invoked as a standalone command without any arguments > > to mitigate security surfaces. > > > > In this patch set, > > Patch#1 to #7 are preparatory patches for patch#8. > > Patch#8 is a core part of reworking. > > Patch#9 is for standalone boot manager. > > Hello Takahiro, > > your patches 1-8 are now (with some modifications) in the efi-2019-07 > branch. I have added some more patches. > > https://github.com/xypron2/u-boot/commits/efi-2019-07 > > Travis CI testing was ok: > https://travis-ci.org/xypron2/u-boot/builds/522947698 > > I have tested on real hardware without error: > * TinkerBoard (32 bit) boot via GRUB > * Pine64 A64 LTS (64 bit) boot via iPXE and GRUB > * Odroid C2 (64 bit) boot via GRUB > > If you are ok with the adjustments to your patch series I will create a > pull request. Thank you for the merge. One question: how did you fix a grub error that you reported before? -Takahiro Akashi > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tbs2910 not buildable
On Sun, Apr 14, 2019 at 12:46:25PM +0200, Soeren Moch wrote: > Hi Stefano, > > On 14.04.19 11:52, stefano babic wrote: > > Hallo Soeren, > > > > after pulling from Tom and merging u-boot-imx, - next, your board is not > > buildable anymore. Better: it is buildable, but size exceeds: > > > >arm: + tbs2910 > > +u-boot.imx exceeds file size limit: > > + limit: 392192 bytes > > + actual: 396288 bytes > > + excess: 4096 bytes > > > > Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this > > board), solves the issue. I can do myself in this way or let me know > > what is your preferred way. > > > Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it > is supposed to provide a full PC environment. It supports booting from > SATA, and such disk may as well be partitioned with EFI. It is really > terrible to drop user visible features, just to support a new "driver > model" that is supposed to ease life for developers, but in fact is much > work and a real pain for maintainers of existing boards, and brings > exactly nothing for the board's users. > > So much for that. Now to your question. > > Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more > important to get this series merged, because other boards also depend on > the SATA patches. We can readd EFI_PARTITION support later. For sure > there will be more patches in this development cycle. > But if you can wait a few hours, I will look for a better solution, or > send a formal patch for this CONFIG_EFI_PARTITION removal. Now that I'm back from vacation, I do want to chime in here. So, yes, this presents a difficult challenge. I don't want to encourage people to take out functionality just to make the binary fit. And I assume the binary size limit is so that we don't overwrite something else, so we can't just grow it either. So what options do we have? Taking out CONFIG_DM_WARN and CONFIG_MMC_VERBOSE gives us about 2KB. Changing the loglevel from 4 to 3 saves another 2KB. Dropping the memtest command (which is not helpful and discouraged) gives another 1KB. But these are also, well, stopgaps. Is it all going to be worth it? Well, I hope so. We can for example gain another 1KB back by disabling block cache, which does improve read speed from filesystems and thus something end users see. But it could have been written without DM, it's just a new feature and "carrot" to move to DM. I don't even see any obvious-to-me cases of including big hunks of data that should be dropped, so that brings us to maybe-not-used functionality like bootelf/bootvx/nfs and so on. Which I don't like. So, I'm trying to keep a harder still eye on size growth when pulling in functionality. And I kinda wish LTO was easier to bring in as that might really save us some space. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: check length in CreateDeviceNode()
When creating a device path node ensure that the size of the allocated
memory at lest matches the size of the node header.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 6104c7d33b..10f890f44f 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -335,6 +335,9 @@ struct efi_device_path *efi_dp_create_device_node(const u8
type,
{
struct efi_device_path *ret;
+ if (length < sizeof(struct efi_device_path))
+ return NULL;
+
ret = dp_alloc(length);
if (!ret)
return ret;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting MX6 via Serial Download after DM conversion
Hi, Has anyone managed to boot i.MX6 via serial download protocol after the conversion to DM? On a mx6sabresd I can no longer boot via SDP running 2019.04: After running 'sudo ./imx_usb SPL' I get: U-Boot SPL 2019.04 (Apr 22 2019 - 19:45:46 -0300) Trying to boot from USB SDP SDP: initialize... SDP: handle requests.. Then I load the u-boot-dtb.img binary and the following error is seen: $ sudo ./imx_usb u-boot-dtb.img config file vid=0x066f pid=0x3780 file_name=mx23_usb_work.conf vid=0x15a2 pid=0x004f file_name=mx28_usb_work.conf vid=0x15a2 pid=0x0052 file_name=mx50_usb_work.conf vid=0x15a2 pid=0x0054 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0061 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0063 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0071 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x007d file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0080 file_name=mx6_usb_work.conf vid=0x1fc9 pid=0x0128 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0076 file_name=mx7_usb_work.conf vid=0x1fc9 pid=0x0126 file_name=mx7ulp_usb_work.conf vid=0x15a2 pid=0x0041 file_name=mx51_usb_work.conf vid=0x15a2 pid=0x004e file_name=mx53_usb_work.conf vid=0x15a2 pid=0x006a file_name=vybrid_usb_work.conf vid=0x066f pid=0x37ff file_name=linux_gadget.conf vid=0x1b67 pid=0x4fff file_name=mx6_usb_sdp_spl.conf vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf vid=0x1fc9 pid=0x012b file_name=mx8mq_usb_work.conf config file parse /usr/etc/imx-loader.d//mx6_usb_sdp_spl.conf Trying to open device vid=0x0525 pid=0xb4a4 Interface 0 claimed HAB security state: development mode (0x56787856) == work item filename u-boot-dtb.img load_size 0 bytes load_addr 0x dcd 1 clear_dcd 0 plug 1 jump_mode 3 jump_addr 0x == end work item header not found 8400:2e77d044, 4000 do_download failed, err=-22 HAB security state: development mode (0x56787856) With 2019.01 (prior to DM conversion) I can boot via SDP just fine. Does anyone have any suggestions? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: check memory type in AllocatePages()
The UEFI specification prescribes that AllocatePages() checks the memory
type.
Add missing definition of EFI_PERSISTENT_MEMORY_TYPE.
Signed-off-by: Heinrich Schuchardt
---
include/efi.h | 4
lib/efi_loader/efi_memory.c | 4
2 files changed, 8 insertions(+)
diff --git a/include/efi.h b/include/efi.h
index 3c9d20f8c0..5f415a99cc 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -168,6 +168,10 @@ enum efi_mem_type {
* part of the processor.
*/
EFI_PAL_CODE,
+ /*
+* Non-volatile memory.
+*/
+ EFI_PERSISTENT_MEMORY_TYPE,
EFI_MAX_MEMORY_TYPE,
EFI_TABLE_END, /* For efi_build_mem_table() */
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 46681dc208..987cc6dc5f 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -376,6 +376,10 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
efi_status_t r = EFI_SUCCESS;
uint64_t addr;
+ /* Check import parameters */
+ if (memory_type >= EFI_PERSISTENT_MEMORY_TYPE &&
+ memory_type <= 0x6FFF)
+ return EFI_INVALID_PARAMETER;
if (!memory)
return EFI_INVALID_PARAMETER;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND] cmd: image_info: Add checking of default FIT config
On Tue, Mar 12, 2019 at 01:18:46AM +, Bryan O'Donoghue wrote: > This patch adds a check for the default FIT config to iminfo. Once applied > any signing of the config will show a pass fail similar to rsa+/rsa-. > > Output looks like this: > >Hash(es) for Image 0 (kernel@1): sha1+ >Hash(es) for Image 1 (f...@imx7s-warp.dtb): sha1+ >Hash(es) for Image 2 (ramdisk@1): sha1+ >Hash(es) for Image 3 (bootscr): sha1+ >Hash for default configuration: sha1,rsa2048:mbl-fit-rot-key+ > > Signed-off-by: Bryan O'Donoghue > Cc: Jun Nie > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Simon Glass NAK, this blows up a ton of boards with Linksprite_pcDuino and pine_h64 being two examples. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] fit signature: Add fallback of required keys
Validation of fit image configuration signatures does not seem to do a
"fall-back" mechanism as mentioned in doc/uImage.FIT/signature.txt.
The current constraints seem to only allow the following:
- skipping keys not marked "required" (not attempting to validate
with them at all)
- checking a key marked required, but if it does not pass the validation
entirely fails (no fall-back)
This patch keeps the non-required mechanism, however changes the
required key logic to check all keys until a key that can validate the
configuration is found. If none is found, an error is raised as before
and boot is halted.
Signed-off-by: Sam Voss
--
v1->v2:
- Fix comment style
- Fix unused argument in printf
- Fix broken printf argument
---
common/image-sig.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 455f2b9629..15073e60e9 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -446,6 +446,7 @@ int fit_config_verify_required_sigs(const void *fit, int
conf_noffset,
return 0;
}
+ /* Loop until either a valid key is found or we run out of keys */
fdt_for_each_subnode(noffset, sig_blob, sig_node) {
const char *required;
int ret;
@@ -455,14 +456,19 @@ int fit_config_verify_required_sigs(const void *fit, int
conf_noffset,
continue;
ret = fit_config_verify_sig(fit, conf_noffset, sig_blob,
noffset);
- if (ret) {
- printf("Failed to verify required signature '%s'\n",
- fit_get_name(sig_blob, noffset, NULL));
- return ret;
+
+ if (!ret) { /* key verified successfully */
+ return 0;
}
+
+ printf("Failed to verify required signature with key '%s'\n",
+ fit_get_name(sig_blob, noffset, NULL));
}
- return 0;
+ printf("No keys were able to verify required signature\n");
+
+ return -1;
+
}
int fit_config_verify(const void *fit, int conf_noffset)
--
2.14.2.746.g8fb8a94
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: add overall SPL size check
On Mon, Apr 22, 2019 at 10:27:21PM +0200, Simon Goldschmidt wrote: > This adds a size check for SPL that can dynamically check generated > SPL binaries (including devicetree) for a size limit that ensures > this image plus global data, heap and stack fit in initial SRAM. > > Since some of these sizes are not available to make, a new host tool > 'spl_size_limit' is added that dumps the resulting maximum size for > an SPL binary to stdout. This tool is used in toplevel Makefile to > implement the size check on SPL binaries. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: > - added missing tools/spl_size_limit.c > > Kconfig| 8 > Makefile | 2 +- > common/spl/Kconfig | 36 > tools/Makefile | 2 ++ > tools/spl_size_limit.c | 30 ++ Ah, now I get it, and why you said you depend on Heinrich's series now, OK. This isn't quite what I envisioned, but, maybe that's OK. I was thinking we could drop the whole of the shell function, stat() the file and return 0/error. But I guess on the whole we've got the shell function portable and not too fragile looking, so maybe it's not worth the extra work there. I do have one problem I'd like to discuss, which is that to replicate this for a TPL size limit (which we totally have and need to deal with), we cp and sed spl_size_limit.c to tpl_size_limit.c. I don't however see a clever way to avoid that. CONFIG_IS_ENABLED() would let us have the same #if test, but doing size_limit -= CONFIG_SPL_FOO CONFIG_TPL_FOO; is probably getting too clever. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: Zap lpc32xx_ssp driver-related code
On Mon, Apr 22, 2019 at 11:50:22PM +0300, Vladimir Zapolskiy wrote: > Hi Jagan, Tom, > > On 04/19/2019 09:48 AM, Jagan Teki wrote: > > Dropped > > - lpc32xx_ssp driver > > - CONFIG_LPC32XX_SSP, LPC32XX_SSP_TIMEOUT items > > > > Dropped due to: > > - no active updates > > - no dm conversion > > - multiple pings for asking dm-conversion > > I really don't want to rush into moaning, however let me ask you to drop > the reason given above as invalid, otherwise please clarify who were > the addressees of these 'multiple pings'. Indeed. Since it was only last month or so that I setup a low-traffic list for maintainers / custodians for important issues like this, and lots of previous series have been super bad about Cc'ing the right people, it's not appropriate to say "no one has spoken up" or similar lack of reply arguments. I know there's been previous postings of "delete this (and all of the other SPI drivers, and all of the other boards and deletion posts too)" type series but no, they've often not gone out to the right people. > > - no response for dm converted patch > > I believe there was no DM conversion patch for this particular driver, > could it happen that I've missed it? There was, but all of what I said above about Cc applies too: https://patchwork.ozlabs.org/patch/910751/ > > - driver-model migration expiry > > > > Definitely this is a valid reason. > > The good news is that I don't have any strong objection against > the deletion of the driver. > > Why? Recently Quentin Schulz added drivers/spi/pl022_spi.c, and it > provides a support of right the same SPI controller, the new driver > satisfies DM policy. > > Quentin, you may take a look at drivers/spi/lpc32xx_ssp.c before (or > after though) its removal for scavenging any goodies. > > From my side I'd like to test the new driver on one of my boards, > but unfortunately it may take indefinite time, because it will require > some tinkering. Nevertheless, if any LPC32xx specific changes will be > required, they'll be added to the new Quentin's driver. In the end, that sounds like an overall improvement to the situation, even if I'm not happy with how we're getting there. Sorry about the frustration (everyone) here. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: Zap lpc32xx_ssp driver-related code
Hi Jagan, Tom, On 04/19/2019 09:48 AM, Jagan Teki wrote: > Dropped > - lpc32xx_ssp driver > - CONFIG_LPC32XX_SSP, LPC32XX_SSP_TIMEOUT items > > Dropped due to: > - no active updates > - no dm conversion > - multiple pings for asking dm-conversion I really don't want to rush into moaning, however let me ask you to drop the reason given above as invalid, otherwise please clarify who were the addressees of these 'multiple pings'. > - no response for dm converted patch I believe there was no DM conversion patch for this particular driver, could it happen that I've missed it? > - driver-model migration expiry > Definitely this is a valid reason. The good news is that I don't have any strong objection against the deletion of the driver. Why? Recently Quentin Schulz added drivers/spi/pl022_spi.c, and it provides a support of right the same SPI controller, the new driver satisfies DM policy. Quentin, you may take a look at drivers/spi/lpc32xx_ssp.c before (or after though) its removal for scavenging any goodies. From my side I'd like to test the new driver on one of my boards, but unfortunately it may take indefinite time, because it will require some tinkering. Nevertheless, if any LPC32xx specific changes will be required, they'll be added to the new Quentin's driver. -- Best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: add overall SPL size check
On 22.04.19 22:19, Tom Rini wrote: On Mon, Apr 22, 2019 at 09:48:06PM +0200, Simon Goldschmidt wrote: This adds a size check for SPL that can dynamically check generated SPL binaries (including devicetree) for a size limit that ensures this image plus global data, heap and stack fit in initial SRAM. Since some of these sizes are not available to make, a new host tool 'spl_size_limit' is added that dumps the resulting maximum size for an SPL binary to stdout. This tool is used in toplevel Makefile to implement the size check on SPL binaries. Signed-off-by: Simon Goldschmidt OK, this relies on very small parts of: https://patchwork.ozlabs.org/patch/1074741/ from Heinrich and I think it's appropriate to grab his S-o-B line and squash those parts in. Please speak up if either of you object. I'm ok with that. --- Kconfig| 8 Makefile | 2 +- common/spl/Kconfig | 36 tools/Makefile | 2 ++ 4 files changed, 39 insertions(+), 9 deletions(-) The new tool code is missing :) d'oh! I've just sent v2 with the tool included. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] spl: add overall SPL size check
This adds a size check for SPL that can dynamically check generated
SPL binaries (including devicetree) for a size limit that ensures
this image plus global data, heap and stack fit in initial SRAM.
Since some of these sizes are not available to make, a new host tool
'spl_size_limit' is added that dumps the resulting maximum size for
an SPL binary to stdout. This tool is used in toplevel Makefile to
implement the size check on SPL binaries.
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- added missing tools/spl_size_limit.c
Kconfig| 8
Makefile | 2 +-
common/spl/Kconfig | 36
tools/Makefile | 2 ++
tools/spl_size_limit.c | 30 ++
5 files changed, 69 insertions(+), 9 deletions(-)
create mode 100644 tools/spl_size_limit.c
diff --git a/Kconfig b/Kconfig
index ca31bcebde..7a5491bd67 100644
--- a/Kconfig
+++ b/Kconfig
@@ -172,14 +172,6 @@ config TPL_SYS_MALLOC_F_LEN
particular needs this to operate, so that it can allocate the
initial serial device and any others that are needed.
-config SPL_SIZE_LIMIT
- int "Maximum size of SPL image"
- depends on SPL
- default 0
- help
- Specifies the maximum length of the U-Boot SPL image.
- If this value is zero, it is ignored.
-
menuconfig EXPERT
bool "Configure standard U-Boot features (expert users)"
default y
diff --git a/Makefile b/Makefile
index ac375f396c..df674b0e96 100644
--- a/Makefile
+++ b/Makefile
@@ -797,7 +797,7 @@ BOARD_SIZE_CHECK =
endif
ifneq ($(CONFIG_SPL_SIZE_LIMIT),0)
-SPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_SPL_SIZE_LIMIT))
+SPL_SIZE_CHECK = @$(call size_check,$@,$$(tools/spl_size_limit))
else
SPL_SIZE_CHECK =
endif
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 206c24076d..24ddab3a48 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -25,6 +25,42 @@ config SPL_FRAMEWORK
supports MMC, NAND and YMODEM and other methods loading of U-Boot
and the Linux Kernel. If unsure, say Y.
+config SPL_SIZE_LIMIT
+ hex "Maximum size of SPL image"
+ depends on SPL
+ default 0
+ help
+ Specifies the maximum length of the U-Boot SPL image.
+ If this value is zero, it is ignored.
+
+config SPL_SIZE_LIMIT_SUBTRACT_GD
+ bool "SPL image size check: provide space for global data"
+ depends on SPL_SIZE_LIMIT > 0
+ help
+ If enabled, aligned size of global data is reserved in
+ SPL_SIZE_LIMIT check to ensure such an image does not overflow SRAM
+ if SPL_SIZE_LIMIT describes the size of SRAM available for SPL when
+ pre-reloc global data is put into this SRAM, too.
+
+config SPL_SIZE_LIMIT_SUBTRACT_MALLOC
+ bool "SPL image size check: provide space for malloc() pool before
relocation"
+ depends on SPL_SIZE_LIMIT > 0
+ help
+ If enabled, SPL_SYS_MALLOC_F_LEN is reserved in SPL_SIZE_LIMIT check
+ to ensure such an image does not overflow SRAM if SPL_SIZE_LIMIT
+ describes the size of SRAM available for SPL when pre-reloc malloc
+ pool is put into this SRAM, too.
+
+config SPL_SIZE_LIMIT_PROVIDE_STACK
+ hex "SPL image size check: provide stack space before relocation"
+ depends on SPL_SIZE_LIMIT > 0
+ default 0
+ help
+ If set, this size is reserved in SPL_SIZE_LIMIT check to ensure such
+ an image does not overflow SRAM if SPL_SIZE_LIMIT describes the size
+ of SRAM available for SPL when the stack required before reolcation
+ uses this SRAM, too.
+
config HANDOFF
bool "Pass hand-off information from SPL to U-Boot proper"
depends on BLOBLIST
diff --git a/tools/Makefile b/tools/Makefile
index d377d85f74..d3b950553f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -199,6 +199,8 @@ hostprogs-$(CONFIG_RISCV) += prelink-riscv
hostprogs-y += fdtgrep
fdtgrep-objs += $(LIBFDT_OBJS) fdtgrep.o
+hostprogs-y += spl_size_limit
+
hostprogs-$(CONFIG_MIPS) += mips-relocs
# We build some files with extra pedantic flags to try to minimize things
diff --git a/tools/spl_size_limit.c b/tools/spl_size_limit.c
new file mode 100644
index 00..98ff491867
--- /dev/null
+++ b/tools/spl_size_limit.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Simon Goldschmidt
+ *
+ * This tool helps to return the size available for SPL image during build
+ */
+
+#include
+#include
+
+int main(int argc, char *argv[])
+{
+ int spl_size_limit = 0;
+
+#ifdef CONFIG_SPL_SIZE_LIMIT
+ spl_size_limit = CONFIG_SPL_SIZE_LIMIT;
+#ifdef CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD
+ spl_size_limit -= GENERATED_GBL_DATA_SIZE;
+#endif
+#ifdef CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC
+ spl_size_limit -= CONFIG_SPL_SYS_MALLOC_F_LEN;
+#endif
+#ifdef CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK
+
Re: [U-Boot] [PATCH] spl: add overall SPL size check
On Mon, Apr 22, 2019 at 09:48:06PM +0200, Simon Goldschmidt wrote: > This adds a size check for SPL that can dynamically check generated > SPL binaries (including devicetree) for a size limit that ensures > this image plus global data, heap and stack fit in initial SRAM. > > Since some of these sizes are not available to make, a new host tool > 'spl_size_limit' is added that dumps the resulting maximum size for > an SPL binary to stdout. This tool is used in toplevel Makefile to > implement the size check on SPL binaries. > > Signed-off-by: Simon Goldschmidt OK, this relies on very small parts of: https://patchwork.ozlabs.org/patch/1074741/ from Heinrich and I think it's appropriate to grab his S-o-B line and squash those parts in. Please speak up if either of you object. > --- > > Kconfig| 8 > Makefile | 2 +- > common/spl/Kconfig | 36 > tools/Makefile | 2 ++ > 4 files changed, 39 insertions(+), 9 deletions(-) The new tool code is missing :) -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
On 22.04.19 21:29, Tom Rini wrote: On Mon, Apr 22, 2019 at 08:40:52PM +0200, Simon Goldschmidt wrote: Am 22.04.2019 um 16:36 schrieb Tom Rini: On Thu, Apr 18, 2019 at 10:12:36PM +0200, Simon Goldschmidt wrote: Heinrich, On 02.04.19 19:19, Heinrich Schuchardt wrote: The SPL image for the Tinker Board has to fit into 32 KiB. This includes up to 2 KiB for the file header. A new configuration variable CONFIG_SPL_SIZE_LIMIT is introduced to define the board specific limit. A common Makefile function is used for this test and the test against CONFIG_BOARD_SIZE_LIMIT. Move the board size check from arch/arm/mach-imx/Makefile to Makefile. Has anything from this series been applied? I now have a working patch that applies on top of this and adds a full SPL SRAM size check (including HEAP, GD and stack; via a host tool) which works for socfpga (as an example of a platform where SPL binary is loaded to limited SRAM). Actually, my patch would replace your patch 3/4 but build on 1/4 (2/4 and 4/4 are arch-specific). How should we proceed here? I could send a series including your 1/4, or I could send a series completely building on this series, at the downside of more or less reverting your 2/4. What I would like to see is i.MX (and rockchip) converted to use your new test as well (also, yay! Thanks for following up on that!) and we drop the existing check here. Ok, so while I cannot really help on i.MX and rockchip, why don't you accept this series from Heinrich and I'll send my patch as followup? Then we can discuss this with i.MX and rockchip maintainers. Can you post your series now, and we can move from there? Thanks! Did that: https://patchwork.ozlabs.org/patch/1088865/ [Depends on this series from Heinrich] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: add overall SPL size check
This adds a size check for SPL that can dynamically check generated SPL binaries (including devicetree) for a size limit that ensures this image plus global data, heap and stack fit in initial SRAM. Since some of these sizes are not available to make, a new host tool 'spl_size_limit' is added that dumps the resulting maximum size for an SPL binary to stdout. This tool is used in toplevel Makefile to implement the size check on SPL binaries. Signed-off-by: Simon Goldschmidt --- Kconfig| 8 Makefile | 2 +- common/spl/Kconfig | 36 tools/Makefile | 2 ++ 4 files changed, 39 insertions(+), 9 deletions(-) diff --git a/Kconfig b/Kconfig index ca31bcebde..7a5491bd67 100644 --- a/Kconfig +++ b/Kconfig @@ -172,14 +172,6 @@ config TPL_SYS_MALLOC_F_LEN particular needs this to operate, so that it can allocate the initial serial device and any others that are needed. -config SPL_SIZE_LIMIT - int "Maximum size of SPL image" - depends on SPL - default 0 - help - Specifies the maximum length of the U-Boot SPL image. - If this value is zero, it is ignored. - menuconfig EXPERT bool "Configure standard U-Boot features (expert users)" default y diff --git a/Makefile b/Makefile index ac375f396c..df674b0e96 100644 --- a/Makefile +++ b/Makefile @@ -797,7 +797,7 @@ BOARD_SIZE_CHECK = endif ifneq ($(CONFIG_SPL_SIZE_LIMIT),0) -SPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_SPL_SIZE_LIMIT)) +SPL_SIZE_CHECK = @$(call size_check,$@,$$(tools/spl_size_limit)) else SPL_SIZE_CHECK = endif diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..24ddab3a48 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -25,6 +25,42 @@ config SPL_FRAMEWORK supports MMC, NAND and YMODEM and other methods loading of U-Boot and the Linux Kernel. If unsure, say Y. +config SPL_SIZE_LIMIT + hex "Maximum size of SPL image" + depends on SPL + default 0 + help + Specifies the maximum length of the U-Boot SPL image. + If this value is zero, it is ignored. + +config SPL_SIZE_LIMIT_SUBTRACT_GD + bool "SPL image size check: provide space for global data" + depends on SPL_SIZE_LIMIT > 0 + help + If enabled, aligned size of global data is reserved in + SPL_SIZE_LIMIT check to ensure such an image does not overflow SRAM + if SPL_SIZE_LIMIT describes the size of SRAM available for SPL when + pre-reloc global data is put into this SRAM, too. + +config SPL_SIZE_LIMIT_SUBTRACT_MALLOC + bool "SPL image size check: provide space for malloc() pool before relocation" + depends on SPL_SIZE_LIMIT > 0 + help + If enabled, SPL_SYS_MALLOC_F_LEN is reserved in SPL_SIZE_LIMIT check + to ensure such an image does not overflow SRAM if SPL_SIZE_LIMIT + describes the size of SRAM available for SPL when pre-reloc malloc + pool is put into this SRAM, too. + +config SPL_SIZE_LIMIT_PROVIDE_STACK + hex "SPL image size check: provide stack space before relocation" + depends on SPL_SIZE_LIMIT > 0 + default 0 + help + If set, this size is reserved in SPL_SIZE_LIMIT check to ensure such + an image does not overflow SRAM if SPL_SIZE_LIMIT describes the size + of SRAM available for SPL when the stack required before reolcation + uses this SRAM, too. + config HANDOFF bool "Pass hand-off information from SPL to U-Boot proper" depends on BLOBLIST diff --git a/tools/Makefile b/tools/Makefile index d377d85f74..d3b950553f 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -199,6 +199,8 @@ hostprogs-$(CONFIG_RISCV) += prelink-riscv hostprogs-y += fdtgrep fdtgrep-objs += $(LIBFDT_OBJS) fdtgrep.o +hostprogs-y += spl_size_limit + hostprogs-$(CONFIG_MIPS) += mips-relocs # We build some files with extra pedantic flags to try to minimize things -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
On Mon, Apr 22, 2019 at 08:40:52PM +0200, Simon Goldschmidt wrote: > Am 22.04.2019 um 16:36 schrieb Tom Rini: > >On Thu, Apr 18, 2019 at 10:12:36PM +0200, Simon Goldschmidt wrote: > >>Heinrich, > >> > >>On 02.04.19 19:19, Heinrich Schuchardt wrote: > >>>The SPL image for the Tinker Board has to fit into 32 KiB. This includes > >>>up to 2 KiB for the file header. > >>> > >>>A new configuration variable CONFIG_SPL_SIZE_LIMIT is introduced to define > >>>the board specific limit. > >>> > >>>A common Makefile function is used for this test and the test against > >>>CONFIG_BOARD_SIZE_LIMIT. > >>> > >>>Move the board size check from arch/arm/mach-imx/Makefile to Makefile. > >> > >>Has anything from this series been applied? I now have a working patch that > >>applies on top of this and adds a full SPL SRAM size check (including HEAP, > >>GD and stack; via a host tool) which works for socfpga (as an example of a > >>platform where SPL binary is loaded to limited SRAM). > >> > >>Actually, my patch would replace your patch 3/4 but build on 1/4 (2/4 and > >>4/4 are arch-specific). > >> > >>How should we proceed here? I could send a series including your 1/4, or I > >>could send a series completely building on this series, at the downside of > >>more or less reverting your 2/4. > > > >What I would like to see is i.MX (and rockchip) converted to use your > >new test as well (also, yay! Thanks for following up on that!) and we > >drop the existing check here. > > Ok, so while I cannot really help on i.MX and rockchip, why don't you accept > this series from Heinrich and I'll send my patch as followup? Then we can > discuss this with i.MX and rockchip maintainers. Can you post your series now, and we can move from there? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Add support for selecting bridges in bridge command
On 4/22/19 9:18 PM, Simon Goldschmidt wrote: > > > On 22.04.19 20:41, Marek Vasut wrote: >> On 4/22/19 8:22 PM, Simon Goldschmidt wrote: >>> Am 22.04.2019 um 20:01 schrieb Marek Vasut: On 4/19/19 10:00 PM, Simon Goldschmidt wrote: > > > On 17.04.19 22:15, Marek Vasut wrote: >> Add optional "mask" argument to the SoCFPGA bridge command, to select >> which bridges should be enabled/disabled. This allows the user to >> avoid >> enabling bridges which are not connected into the FPGA fabric. >> Default >> behavior is to enable/disable all bridges. > > So does this change the command? Seems like leaving away the new > 'mask' > argument would now lead to enabling all bridges by overwriting > whatever > the handoff values were before? That's how it behaved before though -- all the bridges were enabled. Now it's possible to explicitly select which bridges to enable/disable. >>> >>> As I read the code, before it wrote iswgrp_handoff[x] to the registers. >> >> Nope, before it was the SPL that wrote the iswgrp_handoff registers >> (iswgrp_handoff[0] to 0x0 and iswgrp_handoff[1] to 0x7) >> >>> The question is what is iswgrp_handoff[x]. >> >> Just regular scratch registers with special name. The [0] is used to >> indicate to the software how the brg_mod_reset register is supposed to >> be configured. The [1] is used to indicate how the l3remap register is >> supposed to be configured. >> >> The SPL currently sets these registers as -- all bridges released out of >> reset ; all bridges mapped into the L3 space. I believe this patch does >> not change that behavior. >> >>> It's not the bridges status >>> from Quartus (as the "handoff" suffix might suggest). Instead (if I >>> remember correctly), it's either "all bridges" or "no bridges", >>> depending on the FPGA configuration status at SPL runtime. >>> >>> In this case, we're probably better off with leaving it to the command >>> line scripts to say which bridges shall be enabled... >> >> This patch only changes things in that it updates the handoff registers >> when the user selects a new mask, so that any software which runs after >> U-Boot would be aware of which bridges U-Boot configured. >> >> But maybe I'm missing something obvious, this stuff is so convoluted >> that I'd really appreciate if you could review thoroughly if there's >> something that doesn't seem right. > > Hmm, if you're not 100% sure yourself, let me take the time to check > again. What made me stumble accross this is that "bridge enable" did not > work when no FPGA had been configured during SPL. I'm reasonably sure it's OK, but another pair of eyeballs and all that ... If the FPGA isn't configured, you shouldn't even run bridge enable, the result of that is undefined. > And the duplication of names where U-Boot caches the handoff registers > doesn't really help to make it easy to follow... Look at arch/arm/mach-socfpga/misc_gen5.c do_bridge_reset() , that should clarify how the handoff registers are used. Keep in mind, they are only scratch registers , they have no real impact on the HW (except some are also read by BootROM during warm reset). -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Add support for selecting bridges in bridge command
On 22.04.19 20:41, Marek Vasut wrote: On 4/22/19 8:22 PM, Simon Goldschmidt wrote: Am 22.04.2019 um 20:01 schrieb Marek Vasut: On 4/19/19 10:00 PM, Simon Goldschmidt wrote: On 17.04.19 22:15, Marek Vasut wrote: Add optional "mask" argument to the SoCFPGA bridge command, to select which bridges should be enabled/disabled. This allows the user to avoid enabling bridges which are not connected into the FPGA fabric. Default behavior is to enable/disable all bridges. So does this change the command? Seems like leaving away the new 'mask' argument would now lead to enabling all bridges by overwriting whatever the handoff values were before? That's how it behaved before though -- all the bridges were enabled. Now it's possible to explicitly select which bridges to enable/disable. As I read the code, before it wrote iswgrp_handoff[x] to the registers. Nope, before it was the SPL that wrote the iswgrp_handoff registers (iswgrp_handoff[0] to 0x0 and iswgrp_handoff[1] to 0x7) The question is what is iswgrp_handoff[x]. Just regular scratch registers with special name. The [0] is used to indicate to the software how the brg_mod_reset register is supposed to be configured. The [1] is used to indicate how the l3remap register is supposed to be configured. The SPL currently sets these registers as -- all bridges released out of reset ; all bridges mapped into the L3 space. I believe this patch does not change that behavior. It's not the bridges status from Quartus (as the "handoff" suffix might suggest). Instead (if I remember correctly), it's either "all bridges" or "no bridges", depending on the FPGA configuration status at SPL runtime. In this case, we're probably better off with leaving it to the command line scripts to say which bridges shall be enabled... This patch only changes things in that it updates the handoff registers when the user selects a new mask, so that any software which runs after U-Boot would be aware of which bridges U-Boot configured. But maybe I'm missing something obvious, this stuff is so convoluted that I'd really appreciate if you could review thoroughly if there's something that doesn't seem right. Hmm, if you're not 100% sure yourself, let me take the time to check again. What made me stumble accross this is that "bridge enable" did not work when no FPGA had been configured during SPL. And the duplication of names where U-Boot caches the handoff registers doesn't really help to make it easy to follow... Regards, Simon Reviewed-by: Simon Goldschmidt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: goldsimon/u-boot
On 4/22/19 8:31 PM, Simon Goldschmidt wrote: > The following changes since commit > 6c5f8dd540d7a8eff244d4c27a09451ca12c8d20: > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-21 > 19:00:04 -0400) > > are available in the Git repository at: > > https://github.com/goldsimon/u-boot.git > > for you to fetch changes up to 5ff194620a5ada0bf05d9dc2668d2233289742a6: > > arm: socfpga: clean up board config files (2019-04-22 20:08:59 +0200) Applied, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] arm: socfpga: clean up socfpga_common.h
On 4/22/19 8:23 PM, Simon Goldschmidt wrote: > Am 22.04.2019 um 20:13 schrieb Marek Vasut: >> On 4/22/19 8:09 PM, Simon Goldschmidt wrote: >>> This series cleans up the include/configs/socfpga_common.h file a bit. >>> >>> It removes some defines that are used nowhere and cleans up some >>> leftovers after various subsystems have been converted to use DM. >>> >>> Changes in v3: >>> - changed commit message of 2/4: s/defines/macros and comments/ >>> >>> Changes in v2: >>> - added (this) patch to move socfpga_vining to DM_I2C >>> - remove even more outdated things >>> - added (this) patch with further cleanups to the socfpga board config >>> files >>> >>> Simon Goldschmidt (4): >>> arm: socfpga: move vining_fpga to DM_I2C >>> arm: socfpga: clean up socfpga_common.h >>> arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ >>> arm: socfpga: clean up board config files >>> >>> configs/socfpga_vining_fpga_defconfig | 8 ++- >>> include/configs/socfpga_arria10_socdk.h | 6 --- >>> include/configs/socfpga_arria5_socdk.h | 2 - >>> include/configs/socfpga_common.h | 68 >>> include/configs/socfpga_cyclone5_socdk.h | 2 - >>> include/configs/socfpga_de0_nano_soc.h | 2 - >>> include/configs/socfpga_de10_nano.h | 2 - >>> include/configs/socfpga_de1_soc.h | 2 - >>> include/configs/socfpga_is1.h | 2 - >>> include/configs/socfpga_sockit.h | 2 - >>> include/configs/socfpga_socrates.h | 2 - >>> include/configs/socfpga_sr1500.h | 11 >>> include/configs/socfpga_vining_fpga.h | 18 --- >>> 13 files changed, 7 insertions(+), 120 deletions(-) >> >> I wanted to pick the whole thing, but it doesn't apply to >> u-boot-socfpga/master or u-boot/master . Can you please rebase it ? I >> pushed updated u-boot-socfpga/master , which matches u-boot/master . >> > > I'm preparing a pull request. This was just for the patch being on the > list. Sorry, I should have mentioned that. > > The reason it doesn't apply is that it depens on other patches. Fine, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Add support for selecting bridges in bridge command
On 4/22/19 8:22 PM, Simon Goldschmidt wrote: > Am 22.04.2019 um 20:01 schrieb Marek Vasut: >> On 4/19/19 10:00 PM, Simon Goldschmidt wrote: >>> >>> >>> On 17.04.19 22:15, Marek Vasut wrote: Add optional "mask" argument to the SoCFPGA bridge command, to select which bridges should be enabled/disabled. This allows the user to avoid enabling bridges which are not connected into the FPGA fabric. Default behavior is to enable/disable all bridges. >>> >>> So does this change the command? Seems like leaving away the new 'mask' >>> argument would now lead to enabling all bridges by overwriting whatever >>> the handoff values were before? >> >> That's how it behaved before though -- all the bridges were enabled. >> Now it's possible to explicitly select which bridges to enable/disable. > > As I read the code, before it wrote iswgrp_handoff[x] to the registers. Nope, before it was the SPL that wrote the iswgrp_handoff registers (iswgrp_handoff[0] to 0x0 and iswgrp_handoff[1] to 0x7) > The question is what is iswgrp_handoff[x]. Just regular scratch registers with special name. The [0] is used to indicate to the software how the brg_mod_reset register is supposed to be configured. The [1] is used to indicate how the l3remap register is supposed to be configured. The SPL currently sets these registers as -- all bridges released out of reset ; all bridges mapped into the L3 space. I believe this patch does not change that behavior. > It's not the bridges status > from Quartus (as the "handoff" suffix might suggest). Instead (if I > remember correctly), it's either "all bridges" or "no bridges", > depending on the FPGA configuration status at SPL runtime. > > In this case, we're probably better off with leaving it to the command > line scripts to say which bridges shall be enabled... This patch only changes things in that it updates the handoff registers when the user selects a new mask, so that any software which runs after U-Boot would be aware of which bridges U-Boot configured. But maybe I'm missing something obvious, this stuff is so convoluted that I'd really appreciate if you could review thoroughly if there's something that doesn't seem right. > Reviewed-by: Simon Goldschmidt > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
Am 22.04.2019 um 16:36 schrieb Tom Rini: On Thu, Apr 18, 2019 at 10:12:36PM +0200, Simon Goldschmidt wrote: Heinrich, On 02.04.19 19:19, Heinrich Schuchardt wrote: The SPL image for the Tinker Board has to fit into 32 KiB. This includes up to 2 KiB for the file header. A new configuration variable CONFIG_SPL_SIZE_LIMIT is introduced to define the board specific limit. A common Makefile function is used for this test and the test against CONFIG_BOARD_SIZE_LIMIT. Move the board size check from arch/arm/mach-imx/Makefile to Makefile. Has anything from this series been applied? I now have a working patch that applies on top of this and adds a full SPL SRAM size check (including HEAP, GD and stack; via a host tool) which works for socfpga (as an example of a platform where SPL binary is loaded to limited SRAM). Actually, my patch would replace your patch 3/4 but build on 1/4 (2/4 and 4/4 are arch-specific). How should we proceed here? I could send a series including your 1/4, or I could send a series completely building on this series, at the downside of more or less reverting your 2/4. What I would like to see is i.MX (and rockchip) converted to use your new test as well (also, yay! Thanks for following up on that!) and we drop the existing check here. Ok, so while I cannot really help on i.MX and rockchip, why don't you accept this series from Heinrich and I'll send my patch as followup? Then we can discuss this with i.MX and rockchip maintainers. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] efi_loader: need either ACPI table or device tree
> From: Heinrich Schuchardt > Date: Mon, 22 Apr 2019 20:01:01 +0200 > > The EBBR specification prescribes that we should have either an ACPI table > or a device tree but not both. Let us enforce this condition in the > `bootefi` command. Why? While I agree that it would be good if U-Boot would provide a device tree I think you're needlessly restricting users here. Many EFI bootloaders (GRUB, OpenBSD's bootloader on arm/arm64) have a way to load a device tree afterwards. This diff makes it impossible to use that capability on systems where U-Boot doesn't provide a device tree. Such a system obviously wouldn't be compliant with the EBBR specification. But together with an appropriate bootloader it could still run an EBBR compliant OS. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: goldsimon/u-boot
The following changes since commit 6c5f8dd540d7a8eff244d4c27a09451ca12c8d20: Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-21 19:00:04 -0400) are available in the Git repository at: https://github.com/goldsimon/u-boot.git for you to fetch changes up to 5ff194620a5ada0bf05d9dc2668d2233289742a6: arm: socfpga: clean up board config files (2019-04-22 20:08:59 +0200) Simon Goldschmidt (15): socfpga: add Simon Goldschmidt as co-custodian eeprom: fix DM_I2C support without CONFIG_SYS_I2C_EEPROM_BUS Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT" i2c: designware: fix reset handling on socfpga gen5 rtc: m41t62: add compatible for m41t82 arm: socfpga: socrates: make rtc work configs: socfpga: socrates: enable rtc support arm: socfpga: fix comment about SPL memory layout arm: socfpga: put initial U-Boot stack into DDR arm: socfpga: imply/default common config options arm: socfpga: gen5: reduce SPL pre-reloc malloc arm: socfpga: move vining_fpga to DM_I2C arm: socfpga: clean up socfpga_common.h arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ arm: socfpga: clean up board config files MAINTAINERS | 1 + arch/arm/Kconfig | 2 ++ arch/arm/mach-socfpga/Kconfig| 23 +++ board/ebv/socrates/qts/iocsr_config.h| 2 +- cmd/Kconfig | 1 - cmd/eeprom.c | 23 +-- configs/socfpga_arria10_defconfig| 6 configs/socfpga_arria5_defconfig | 10 --- configs/socfpga_cyclone5_defconfig | 10 --- configs/socfpga_dbm_soc1_defconfig | 10 --- configs/socfpga_de0_nano_soc_defconfig | 10 --- configs/socfpga_de10_nano_defconfig | 10 --- configs/socfpga_de1_soc_defconfig| 10 --- configs/socfpga_is1_defconfig| 8 -- configs/socfpga_sockit_defconfig | 10 --- configs/socfpga_socrates_defconfig | 12 ++-- configs/socfpga_sr1500_defconfig | 10 --- configs/socfpga_stratix10_defconfig | 2 -- configs/socfpga_vining_fpga_defconfig| 18 +--- doc/git-mailrc | 3 +- drivers/i2c/designware_i2c.c | 20 + drivers/rtc/m41t62.c | 11 include/configs/socfpga_arria10_socdk.h | 6 include/configs/socfpga_arria5_socdk.h | 2 -- include/configs/socfpga_common.h | 116 +++- include/configs/socfpga_cyclone5_socdk.h | 2 -- include/configs/socfpga_de0_nano_soc.h | 2 -- include/configs/socfpga_de10_nano.h | 2 -- include/configs/socfpga_de1_soc.h| 2 -- include/configs/socfpga_is1.h| 2 -- include/configs/socfpga_sockit.h | 2 -- include/configs/socfpga_socrates.h | 2 -- include/configs/socfpga_sr1500.h | 11 include/configs/socfpga_vining_fpga.h| 18 34 files changed, 101 insertions(+), 278 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] arm: socfpga: clean up socfpga_common.h
Am 22.04.2019 um 20:13 schrieb Marek Vasut: On 4/22/19 8:09 PM, Simon Goldschmidt wrote: This series cleans up the include/configs/socfpga_common.h file a bit. It removes some defines that are used nowhere and cleans up some leftovers after various subsystems have been converted to use DM. Changes in v3: - changed commit message of 2/4: s/defines/macros and comments/ Changes in v2: - added (this) patch to move socfpga_vining to DM_I2C - remove even more outdated things - added (this) patch with further cleanups to the socfpga board config files Simon Goldschmidt (4): arm: socfpga: move vining_fpga to DM_I2C arm: socfpga: clean up socfpga_common.h arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ arm: socfpga: clean up board config files configs/socfpga_vining_fpga_defconfig| 8 ++- include/configs/socfpga_arria10_socdk.h | 6 --- include/configs/socfpga_arria5_socdk.h | 2 - include/configs/socfpga_common.h | 68 include/configs/socfpga_cyclone5_socdk.h | 2 - include/configs/socfpga_de0_nano_soc.h | 2 - include/configs/socfpga_de10_nano.h | 2 - include/configs/socfpga_de1_soc.h| 2 - include/configs/socfpga_is1.h| 2 - include/configs/socfpga_sockit.h | 2 - include/configs/socfpga_socrates.h | 2 - include/configs/socfpga_sr1500.h | 11 include/configs/socfpga_vining_fpga.h| 18 --- 13 files changed, 7 insertions(+), 120 deletions(-) I wanted to pick the whole thing, but it doesn't apply to u-boot-socfpga/master or u-boot/master . Can you please rebase it ? I pushed updated u-boot-socfpga/master , which matches u-boot/master . I'm preparing a pull request. This was just for the patch being on the list. Sorry, I should have mentioned that. The reason it doesn't apply is that it depens on other patches. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Add support for selecting bridges in bridge command
Am 22.04.2019 um 20:01 schrieb Marek Vasut: On 4/19/19 10:00 PM, Simon Goldschmidt wrote: On 17.04.19 22:15, Marek Vasut wrote: Add optional "mask" argument to the SoCFPGA bridge command, to select which bridges should be enabled/disabled. This allows the user to avoid enabling bridges which are not connected into the FPGA fabric. Default behavior is to enable/disable all bridges. So does this change the command? Seems like leaving away the new 'mask' argument would now lead to enabling all bridges by overwriting whatever the handoff values were before? That's how it behaved before though -- all the bridges were enabled. Now it's possible to explicitly select which bridges to enable/disable. As I read the code, before it wrote iswgrp_handoff[x] to the registers. The question is what is iswgrp_handoff[x]. It's not the bridges status from Quartus (as the "handoff" suffix might suggest). Instead (if I remember correctly), it's either "all bridges" or "no bridges", depending on the FPGA configuration status at SPL runtime. In this case, we're probably better off with leaving it to the command line scripts to say which bridges shall be enabled... Reviewed-by: Simon Goldschmidt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: socfpga: Factor out handoff register configuration
Am 22.04.2019 um 19:59 schrieb Marek Vasut:
On 4/19/19 9:47 PM, Simon Goldschmidt wrote:
On 17.04.19 22:15, Marek Vasut wrote:
Factor out the code for programming preloader handoff register values,
the ISWGRP Handoff 0 and 1. These registers later control which bridges
are enabled by the "bridge" command on Gen5 devices.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
---
.../include/mach/reset_manager_gen5.h | 1 +
arch/arm/mach-socfpga/reset_manager_gen5.c | 25 +--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
index dd58922cec..5e490d182e 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
@@ -9,6 +9,7 @@
#include
void reset_deassert_peripherals_handoff(void);
+void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h);
void socfpga_bridges_reset(int enable);
struct socfpga_reset_manager {
diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c
b/arch/arm/mach-socfpga/reset_manager_gen5.c
index 25baef79bc..66af924485 100644
--- a/arch/arm/mach-socfpga/reset_manager_gen5.c
+++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
@@ -73,6 +73,28 @@ void reset_deassert_peripherals_handoff(void)
#define L3REGS_REMAP_HPS2FPGA_MASK 0x08
#define L3REGS_REMAP_OCRAM_MASK 0x01
+void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h)
+{
+ u32 brgmask = 0x0;
+ u32 l3rmask = L3REGS_REMAP_OCRAM_MASK;
+
+ if (h2f)
+ brgmask |= BIT(0);
+ else
+ l3rmask |= L3REGS_REMAP_HPS2FPGA_MASK;
+
+ if (lwh2f)
+ brgmask |= BIT(1);
+ else
+ l3rmask |= L3REGS_REMAP_LWHPS2FPGA_MASK;
+
+ if (f2h)
+ brgmask |= BIT(2);
+
+ writel(brgmask, _regs->iswgrp_handoff[0]);
+ writel(l3rmask, _regs->iswgrp_handoff[1]);
+}
+
void socfpga_bridges_reset(int enable)
{
const u32 l3mask = L3REGS_REMAP_LWHPS2FPGA_MASK |
'l3mask' seems unused after this change, no?
Nope, it's still used in the else {} branch of the conditional below.
Oops, missed that. In that case:
Reviewed-by: Simon Goldschmidt
[...]
@@ -83,8 +105,7 @@ void socfpga_bridges_reset(int enable)
/* brdmodrst */
writel(0x, _manager_base->brg_mod_reset);
} else {
- writel(0, _regs->iswgrp_handoff[0]);
- writel(l3mask, _regs->iswgrp_handoff[1]);
+ socfpga_bridges_set_handoff_regs(false, false, false);
/* Check signal from FPGA. */
if (!fpgamgr_test_fpga_ready()) {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] efi_loader: rework bootefi/bootmgr
On 4/19/19 5:22 AM, AKASHI Takahiro wrote: > There are several reasons that I want to rework/refactor bootefi command > as well as bootmgr: > * Some previous commits on bootefi.c have made the code complicated > and a bit hard to understand. > > * do_bootefi_exec() would better be implemented using load_image() along > with start_image() to be aligned with UEFI interfaces. > > * Contrary to the other part, efi_selftest part of the code is unusual > in terms of loading/execution path in do_bootefi(). > > * When we will support "secure boot" in the future, EFI Boot Manager > is expected to be invoked as a standalone command without any arguments > to mitigate security surfaces. > > In this patch set, > Patch#1 to #7 are preparatory patches for patch#8. > Patch#8 is a core part of reworking. > Patch#9 is for standalone boot manager. Hello Takahiro, your patches 1-8 are now (with some modifications) in the efi-2019-07 branch. I have added some more patches. https://github.com/xypron2/u-boot/commits/efi-2019-07 Travis CI testing was ok: https://travis-ci.org/xypron2/u-boot/builds/522947698 I have tested on real hardware without error: * TinkerBoard (32 bit) boot via GRUB * Pine64 A64 LTS (64 bit) boot via iPXE and GRUB * Odroid C2 (64 bit) boot via GRUB If you are ok with the adjustments to your patch series I will create a pull request. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Add support for selecting bridges in bridge command
On 4/19/19 10:00 PM, Simon Goldschmidt wrote: > > > On 17.04.19 22:15, Marek Vasut wrote: >> Add optional "mask" argument to the SoCFPGA bridge command, to select >> which bridges should be enabled/disabled. This allows the user to avoid >> enabling bridges which are not connected into the FPGA fabric. Default >> behavior is to enable/disable all bridges. > > So does this change the command? Seems like leaving away the new 'mask' > argument would now lead to enabling all bridges by overwriting whatever > the handoff values were before? That's how it behaved before though -- all the bridges were enabled. Now it's possible to explicitly select which bridges to enable/disable. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: socfpga: Factor out handoff register configuration
On 4/19/19 9:47 PM, Simon Goldschmidt wrote:
>
>
> On 17.04.19 22:15, Marek Vasut wrote:
>> Factor out the code for programming preloader handoff register values,
>> the ISWGRP Handoff 0 and 1. These registers later control which bridges
>> are enabled by the "bridge" command on Gen5 devices.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Chin Liang See
>> Cc: Dinh Nguyen
>> Cc: Simon Goldschmidt
>> Cc: Tien Fong Chee
>> ---
>> .../include/mach/reset_manager_gen5.h | 1 +
>> arch/arm/mach-socfpga/reset_manager_gen5.c | 25 +--
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
>> b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
>> index dd58922cec..5e490d182e 100644
>> --- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
>> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
>> @@ -9,6 +9,7 @@
>> #include
>> void reset_deassert_peripherals_handoff(void);
>> +void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h);
>> void socfpga_bridges_reset(int enable);
>> struct socfpga_reset_manager {
>> diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c
>> b/arch/arm/mach-socfpga/reset_manager_gen5.c
>> index 25baef79bc..66af924485 100644
>> --- a/arch/arm/mach-socfpga/reset_manager_gen5.c
>> +++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
>> @@ -73,6 +73,28 @@ void reset_deassert_peripherals_handoff(void)
>> #define L3REGS_REMAP_HPS2FPGA_MASK 0x08
>> #define L3REGS_REMAP_OCRAM_MASK 0x01
>> +void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h)
>> +{
>> + u32 brgmask = 0x0;
>> + u32 l3rmask = L3REGS_REMAP_OCRAM_MASK;
>> +
>> + if (h2f)
>> + brgmask |= BIT(0);
>> + else
>> + l3rmask |= L3REGS_REMAP_HPS2FPGA_MASK;
>> +
>> + if (lwh2f)
>> + brgmask |= BIT(1);
>> + else
>> + l3rmask |= L3REGS_REMAP_LWHPS2FPGA_MASK;
>> +
>> + if (f2h)
>> + brgmask |= BIT(2);
>> +
>> + writel(brgmask, _regs->iswgrp_handoff[0]);
>> + writel(l3rmask, _regs->iswgrp_handoff[1]);
>> +}
>> +
>> void socfpga_bridges_reset(int enable)
>> {
>> const u32 l3mask = L3REGS_REMAP_LWHPS2FPGA_MASK |
>
> 'l3mask' seems unused after this change, no?
Nope, it's still used in the else {} branch of the conditional below.
[...]
>> @@ -83,8 +105,7 @@ void socfpga_bridges_reset(int enable)
>> /* brdmodrst */
>> writel(0x, _manager_base->brg_mod_reset);
>> } else {
>> - writel(0, _regs->iswgrp_handoff[0]);
>> - writel(l3mask, _regs->iswgrp_handoff[1]);
>> + socfpga_bridges_set_handoff_regs(false, false, false);
>> /* Check signal from FPGA. */
>> if (!fpgamgr_test_fpga_ready()) {
>>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: socfpga: mailbox: Fix off-by-one error on command length checking
On 4/22/19 3:20 AM, Ley Foon Tan wrote: > On Sun, Apr 21, 2019 at 4:30 PM Marek Vasut wrote: >> >> On 4/19/19 10:52 PM, Simon Goldschmidt wrote: >>> >>> >>> Marek Vasut mailto:ma...@denx.de>> schrieb am Fr., 19. >>> Apr. 2019, 11:29: >>> >>> On 4/19/19 8:17 AM, Ley Foon Tan wrote: >>> > A mailbox command contains 1-DWORD header + arguments. The "len" >>> variable >>> > only contains the length of the arguments, but not the 1-DWORD header. >>> > Include the length of header when checking the ring buffer space to >>> > prevent off-by-one error. >>> >>> How long is a DWORD ? Windows API (which we have nothing to do with) >>> defines that as 32bit type, "typedef unsigned long DWORD;", see [1]. >>> But the patch below fixes an off-by-one error , not off by four error ? >>> >>> >>> As all the macros for that mailbox seem to do u32 index access only, I'd >>> be ok with the commit message if it didn't use the term 'DWORD'... >> >> Does that mean MBOX_CMD_BUFFER_SIZE is not in byte units, but in u32 units ? > Yes, it is in u32 unit. One slot location is u32. > How about change DWORD to u32 in commit message? Yes please. It would also make sense to add a comment into the code that len is not in bytes, but u32 units . -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] arm: socfpga: clean up socfpga_common.h
On 4/22/19 8:09 PM, Simon Goldschmidt wrote: > This series cleans up the include/configs/socfpga_common.h file a bit. > > It removes some defines that are used nowhere and cleans up some > leftovers after various subsystems have been converted to use DM. > > Changes in v3: > - changed commit message of 2/4: s/defines/macros and comments/ > > Changes in v2: > - added (this) patch to move socfpga_vining to DM_I2C > - remove even more outdated things > - added (this) patch with further cleanups to the socfpga board config > files > > Simon Goldschmidt (4): > arm: socfpga: move vining_fpga to DM_I2C > arm: socfpga: clean up socfpga_common.h > arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ > arm: socfpga: clean up board config files > > configs/socfpga_vining_fpga_defconfig| 8 ++- > include/configs/socfpga_arria10_socdk.h | 6 --- > include/configs/socfpga_arria5_socdk.h | 2 - > include/configs/socfpga_common.h | 68 > include/configs/socfpga_cyclone5_socdk.h | 2 - > include/configs/socfpga_de0_nano_soc.h | 2 - > include/configs/socfpga_de10_nano.h | 2 - > include/configs/socfpga_de1_soc.h| 2 - > include/configs/socfpga_is1.h| 2 - > include/configs/socfpga_sockit.h | 2 - > include/configs/socfpga_socrates.h | 2 - > include/configs/socfpga_sr1500.h | 11 > include/configs/socfpga_vining_fpga.h| 18 --- > 13 files changed, 7 insertions(+), 120 deletions(-) I wanted to pick the whole thing, but it doesn't apply to u-boot-socfpga/master or u-boot/master . Can you please rebase it ? I pushed updated u-boot-socfpga/master , which matches u-boot/master . -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] arm: socfpga: clean up socfpga_common.h
Remove outdated macros and comments (not used any more, outdated due to DM conversion) from socfpga_common.h. Signed-off-by: Simon Goldschmidt --- Changes in v3: - changed commit message: s/defines/macros and comments/ Changes in v2: - remove even more outdated things include/configs/socfpga_common.h | 40 1 file changed, 40 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index a65fc804e3..5b5e5f5d43 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -72,29 +72,12 @@ #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot argument buffer size */ -#ifndef CONFIG_SYS_HOSTNAME -#define CONFIG_SYS_HOSTNAMECONFIG_SYS_BOARD -#endif - /* * Cache */ #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS -/* - * EPCS/EPCQx1 Serial Flash Controller - */ -#ifdef CONFIG_ALTERA_SPI -/* - * The base address is configurable in QSys, each board must specify the - * base address based on it's particular FPGA configuration. Please note - * that the address here is incremented by 0x400 from the Base address - * selected in QSys, since the SPI registers are at offset +0x400. - * #define CONFIG_SYS_SPI_BASE 0xff240400 - */ -#endif - /* * Ethernet on SoC (EMAC) */ @@ -162,15 +145,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz() #endif -/* - * Designware SPI support - */ - -/* - * Serial Driver - */ -#define CONFIG_SYS_NS16550_SERIAL - /* * USB */ @@ -206,20 +180,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_ENV_SECT_SIZE (64 * 1024) #endif -/* - * mtd partitioning for serial NOR flash - * - * device nor0 , # parts = 6 - * #: namesizeoffset mask_flags - * 0: u-boot 0x0010 0x 0 - * 1: env10x0004 0x0010 0 - * 2: env20x0004 0x0014 0 - * 3: UBI 0x03e8 0x0018 0 - * 4: boot0x00e8 0x0018 0 - * 5: rootfs 0x0100 0x0100 0 - * - */ - /* * SPL * -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] arm: socfpga: clean up board config files
Remove outdated defines (not used any more, outdated due to DM conversion) from various socfpga files in include/config. Signed-off-by: Simon Goldschmidt Acked-by: Marek Vasut --- Changes in v3: None Changes in v2: - added (this) patch with further cleanups to the socfpga board config files include/configs/socfpga_arria10_socdk.h | 6 -- include/configs/socfpga_arria5_socdk.h | 2 -- include/configs/socfpga_cyclone5_socdk.h | 2 -- include/configs/socfpga_de0_nano_soc.h | 2 -- include/configs/socfpga_de10_nano.h | 2 -- include/configs/socfpga_de1_soc.h| 2 -- include/configs/socfpga_is1.h| 2 -- include/configs/socfpga_sockit.h | 2 -- include/configs/socfpga_socrates.h | 2 -- include/configs/socfpga_sr1500.h | 11 --- include/configs/socfpga_vining_fpga.h| 9 - 11 files changed, 42 deletions(-) diff --git a/include/configs/socfpga_arria10_socdk.h b/include/configs/socfpga_arria10_socdk.h index 0f116fbf2d..92630c5e6e 100644 --- a/include/configs/socfpga_arria10_socdk.h +++ b/include/configs/socfpga_arria10_socdk.h @@ -19,12 +19,6 @@ /* Memory configurations */ #define PHYS_SDRAM_1_SIZE 0x4000 -/* Ethernet on SoC (EMAC) */ - -/* - * U-Boot environment configurations - */ - /* * Serial / UART configurations */ diff --git a/include/configs/socfpga_arria5_socdk.h b/include/configs/socfpga_arria5_socdk.h index 24fcdd8b5a..af6137aeb1 100644 --- a/include/configs/socfpga_arria5_socdk.h +++ b/include/configs/socfpga_arria5_socdk.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 18da8496ef..028db2a09e 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index d3224d5bd3..21108e3447 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de10_nano.h b/include/configs/socfpga_de10_nano.h index 2fcabff8af..d85f98fbd4 100644 --- a/include/configs/socfpga_de10_nano.h +++ b/include/configs/socfpga_de10_nano.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de1_soc.h b/include/configs/socfpga_de1_soc.h index f37099c58f..9919d292dc 100644 --- a/include/configs/socfpga_de1_soc.h +++ b/include/configs/socfpga_de1_soc.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h index c233c208a5..c4da5947f3 100644 --- a/include/configs/socfpga_is1.h +++ b/include/configs/socfpga_is1.h @@ -19,8 +19,6 @@ /* Ethernet on SoC (EMAC) */ #if defined(CONFIG_CMD_NET) #define CONFIG_ARP_TIMEOUT 500UL - -/* PHY */ #endif /* The rest of the configuration is shared */ diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h index 3a7f354914..97249a 100644 --- a/include/configs/socfpga_sockit.h +++ b/include/configs/socfpga_sockit.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h index f0d9347891..7faea150a9 100644 --- a/include/configs/socfpga_socrates.h +++ b/include/configs/socfpga_socrates.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h index b6a98611c0..3a8ccc3021 100644 --- a/include/configs/socfpga_sr1500.h +++ b/include/configs/socfpga_sr1500.h @@ -19,8 +19,6 @@ /* The PHY is autodetected, so no MII PHY address is needed here */ #define PHY_ANEG_TIMEOUT
[U-Boot] [PATCH v3 3/4] arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ
socfpga_common.h defines CONFIG_SYS_BOOTMAPSZ to 64 MiB. Since having this define overrides the 'bootm_size' env variable for the whole socfpga platform, let's remove this define from socfpga_common.h and instead rely on the 'bootm_size' env variable (which is initialized to 160 MiB in the same file's default env). This gives users the chance to override it in their own environment. Signed-off-by: Simon Goldschmidt Acked-by: Marek Vasut --- Changes in v3: None Changes in v2: None include/configs/socfpga_common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 5b5e5f5d43..5eccb01d1d 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -10,8 +10,6 @@ */ #define CONFIG_CLOCKS -#define CONFIG_SYS_BOOTMAPSZ (64 * 1024 * 1024) - #define CONFIG_TIMESTAMP /* Print image info with timestamp */ /* -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] arm: socfpga: move vining_fpga to DM_I2C
All socfpga boards except for vining_fpga use DM_I2C. Enable DM_I2C for this board and set the EEPROM defines via Kconfig (enabling CONFIG_I2C_EEPROM from MISC). Signed-off-by: Simon Goldschmidt --- Changes in v3: None Changes in v2: - added (this) patch to move socfpga_vining to DM_I2C configs/socfpga_vining_fpga_defconfig | 8 +++- include/configs/socfpga_common.h | 26 -- include/configs/socfpga_vining_fpga.h | 9 - 3 files changed, 7 insertions(+), 36 deletions(-) diff --git a/configs/socfpga_vining_fpga_defconfig b/configs/socfpga_vining_fpga_defconfig index 7b47b111b7..4a7f775337 100644 --- a/configs/socfpga_vining_fpga_defconfig +++ b/configs/socfpga_vining_fpga_defconfig @@ -16,8 +16,8 @@ CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y -CONFIG_CMD_GREPENV=y CONFIG_CMD_EEPROM=y +CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y @@ -44,6 +44,7 @@ CONFIG_DFU_RAM=y CONFIG_DFU_SF=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_DM_I2C=y CONFIG_LED_STATUS=y CONFIG_LED_STATUS_GPIO=y CONFIG_LED_STATUS0=y @@ -55,6 +56,11 @@ CONFIG_LED_STATUS_BIT2=54 CONFIG_LED_STATUS3=y CONFIG_LED_STATUS_BIT3=65 CONFIG_LED_STATUS_CMD=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x50 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=3 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=70 CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index a501b5209f..a65fc804e3 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -149,32 +149,6 @@ #define CONFIG_SYS_NAND_DATA_BASE SOCFPGA_NANDDATA_ADDRESS #endif -/* - * I2C support - */ -#ifndef CONFIG_DM_I2C -#define CONFIG_SYS_I2C -#define CONFIG_SYS_I2C_BASESOCFPGA_I2C0_ADDRESS -#define CONFIG_SYS_I2C_BASE1 SOCFPGA_I2C1_ADDRESS -#define CONFIG_SYS_I2C_BASE2 SOCFPGA_I2C2_ADDRESS -#define CONFIG_SYS_I2C_BASE3 SOCFPGA_I2C3_ADDRESS -/* Using standard mode which the speed up to 100Kb/s */ -#define CONFIG_SYS_I2C_SPEED 10 -#define CONFIG_SYS_I2C_SPEED1 10 -#define CONFIG_SYS_I2C_SPEED2 10 -#define CONFIG_SYS_I2C_SPEED3 10 -/* Address of device when used as slave */ -#define CONFIG_SYS_I2C_SLAVE 0x02 -#define CONFIG_SYS_I2C_SLAVE1 0x02 -#define CONFIG_SYS_I2C_SLAVE2 0x02 -#define CONFIG_SYS_I2C_SLAVE3 0x02 -#ifndef __ASSEMBLY__ -/* Clock supplied to I2C controller in unit of MHz */ -unsigned int cm_get_l4_sp_clk_hz(void); -#define IC_CLK (cm_get_l4_sp_clk_hz() / 100) -#endif -#endif /* CONFIG_DM_I2C */ - /* * QSPI support */ diff --git a/include/configs/socfpga_vining_fpga.h b/include/configs/socfpga_vining_fpga.h index 5517ed722d..0e547a1295 100644 --- a/include/configs/socfpga_vining_fpga.h +++ b/include/configs/socfpga_vining_fpga.h @@ -16,15 +16,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* I2C EEPROM */ -#ifdef CONFIG_CMD_EEPROM -#define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 -#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 -#define CONFIG_SYS_I2C_EEPROM_BUS 0 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 70 -#endif - /* * Status LEDs: * 0 ... Top Green -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] arm: socfpga: clean up socfpga_common.h
This series cleans up the include/configs/socfpga_common.h file a bit. It removes some defines that are used nowhere and cleans up some leftovers after various subsystems have been converted to use DM. Changes in v3: - changed commit message of 2/4: s/defines/macros and comments/ Changes in v2: - added (this) patch to move socfpga_vining to DM_I2C - remove even more outdated things - added (this) patch with further cleanups to the socfpga board config files Simon Goldschmidt (4): arm: socfpga: move vining_fpga to DM_I2C arm: socfpga: clean up socfpga_common.h arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ arm: socfpga: clean up board config files configs/socfpga_vining_fpga_defconfig| 8 ++- include/configs/socfpga_arria10_socdk.h | 6 --- include/configs/socfpga_arria5_socdk.h | 2 - include/configs/socfpga_common.h | 68 include/configs/socfpga_cyclone5_socdk.h | 2 - include/configs/socfpga_de0_nano_soc.h | 2 - include/configs/socfpga_de10_nano.h | 2 - include/configs/socfpga_de1_soc.h| 2 - include/configs/socfpga_is1.h| 2 - include/configs/socfpga_sockit.h | 2 - include/configs/socfpga_socrates.h | 2 - include/configs/socfpga_sr1500.h | 11 include/configs/socfpga_vining_fpga.h| 18 --- 13 files changed, 7 insertions(+), 120 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 1/1] efi_loader: rework bootmgr/bootefi using load_image API
From: AKASHI Takahiro
In the current implementation, bootefi command and EFI boot manager
don't use load_image API, instead, use more primitive and internal
functions. This will introduce duplicated code and potentially
unknown bugs as well as inconsistent behaviours.
With this patch, do_efibootmgr() and do_boot_efi() are completely
overhauled and re-implemented using load_image API.
Signed-off-by: AKASHI Takahiro
Use efi_root as parent handle for the loaded image.
LoadImage() should be called with BootPolicy = true by the boot manager.
Avoid duplicate free_pool().
Eliminate variable memdp which is not needed after anymore due to
"efi_loader: correctly split device path of loaded image".
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Heinrich Schuchardt
---
v6
Avoid duplicate free_pool().
Eliminate variable memdp which is not needed after anymore due to
"efi_loader: correctly split device path of loaded image".
v5
LoadImage() should be called with BootPolicy = true by the boot
manager
v4
Use efi_root as parent handle for the loaded image.
---
cmd/bootefi.c | 180 ++
include/efi_loader.h | 5 +-
lib/efi_loader/efi_bootmgr.c | 42
lib/efi_loader/efi_boottime.c | 2 +
4 files changed, 119 insertions(+), 110 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index d62e9969acb..be557518309 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -242,89 +242,36 @@ static efi_status_t efi_install_fdt(const char *fdt_opt)
/**
* do_bootefi_exec() - execute EFI binary
*
- * @efi: address of the binary
- * @device_path: path of the device from which the binary was loaded
- * @image_path:device path of the binary
+ * @handle:handle of loaded image
* Return: status code
*
* Load the EFI binary into a newly assigned memory unwinding the relocation
* information, install the loaded image protocol, and call the binary.
*/
-static efi_status_t do_bootefi_exec(void *efi,
- struct efi_device_path *device_path,
- struct efi_device_path *image_path)
+static efi_status_t do_bootefi_exec(efi_handle_t handle)
{
- efi_handle_t mem_handle = NULL;
- struct efi_device_path *memdp = NULL;
efi_status_t ret;
- struct efi_loaded_image_obj *image_obj = NULL;
- struct efi_loaded_image *loaded_image_info = NULL;
-
- /*
-* Special case for efi payload not loaded from disk, such as
-* 'bootefi hello' or for example payload loaded directly into
-* memory via JTAG, etc:
-*/
- if (!device_path && !image_path) {
- printf("WARNING: using memory device/image path, this may
confuse some payloads!\n");
- /* actual addresses filled in after efi_load_pe() */
- memdp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE, 0, 0);
- device_path = image_path = memdp;
- /*
-* Grub expects that the device path of the loaded image is
-* installed on a handle.
-*/
- ret = efi_create_handle(_handle);
- if (ret != EFI_SUCCESS)
- return ret; /* TODO: leaks device_path */
- ret = efi_add_protocol(mem_handle, _guid_device_path,
- device_path);
- if (ret != EFI_SUCCESS)
- goto err_add_protocol;
- } else {
- assert(device_path && image_path);
- }
-
- ret = efi_setup_loaded_image(device_path, image_path, _obj,
-_image_info);
- if (ret)
- goto err_prepare;
/* Transfer environment variable as load options */
- ret = set_load_options((efi_handle_t)image_obj, "bootargs");
- if (ret != EFI_SUCCESS)
- goto err_prepare;
-
- /* Load the EFI payload */
- ret = efi_load_pe(image_obj, efi, loaded_image_info);
+ ret = set_load_options(handle, "bootargs");
if (ret != EFI_SUCCESS)
- goto err_prepare;
-
- if (memdp) {
- struct efi_device_path_memory *mdp = (void *)memdp;
- mdp->memory_type = loaded_image_info->image_code_type;
- mdp->start_address = (uintptr_t)loaded_image_info->image_base;
- mdp->end_address = mdp->start_address +
- loaded_image_info->image_size;
- }
+ return ret;
/* we don't support much: */
env_set("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
"{ro,boot}(blob)");
/* Call our payload! */
- debug("%s: Jumping to 0x%p\n", __func__, image_obj->entry);
- ret = EFI_CALL(efi_start_image(_obj->header, NULL, NULL));
+ ret
[U-Boot] [PATCH 1/1] efi_selftest: do not run FDT test with ACPI table.
The EBBR specification prescribes that we should have either an ACPI table
or a device tree but not both.
So do not run the device tree unit test on boards with an ACPI table.
Hence there is no need any longer to make it 'on request' only.
Do not pass $fdtcontroladdr to `bootefi selftest`.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 4 +++
lib/efi_selftest/efi_selftest_fdt.c | 41 +
test/py/tests/test_efi_selftest.py | 3 ++-
3 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index c9720c9da8..fb82e71976 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -42,6 +42,10 @@ efi_selftest_watchdog.o
obj-$(CONFIG_CPU_V7) += efi_selftest_unaligned.o
obj-$(CONFIG_EFI_LOADER_HII) += efi_selftest_hii.o
+ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
+obj-y += efi_selftest_fdt.o
+endif
+
ifeq ($(CONFIG_BLK)$(CONFIG_PARTITIONS),yy)
obj-y += efi_selftest_block_device.o
endif
diff --git a/lib/efi_selftest/efi_selftest_fdt.c
b/lib/efi_selftest/efi_selftest_fdt.c
index d545d51812..94d72d3f6d 100644
--- a/lib/efi_selftest/efi_selftest_fdt.c
+++ b/lib/efi_selftest/efi_selftest_fdt.c
@@ -13,13 +13,15 @@
#include
#include
-static struct efi_boot_services *boottime;
+static const struct efi_system_table *systemtab;
+static const struct efi_boot_services *boottime;
static const char *fdt;
/* This should be sufficient for */
#define BUFFERSIZE 0x10
-static efi_guid_t fdt_guid = EFI_FDT_GUID;
+static const efi_guid_t fdt_guid = EFI_FDT_GUID;
+static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
/*
* Convert FDT value to host endianness.
@@ -115,6 +117,23 @@ static char *get_property(const u16 *property)
}
}
+/**
+ * efi_st_get_config_table() - get configuration table
+ *
+ * @guid: GUID of the configuration table
+ * Return: pointer to configuration table or NULL
+ */
+static void *efi_st_get_config_table(const efi_guid_t *guid)
+{
+ size_t i;
+
+ for (i = 0; i < systab.nr_tables; i++) {
+ if (!guidcmp(guid, >tables[i].guid))
+ return systemtab->tables[i].table;
+ }
+ return NULL;
+}
+
/*
* Setup unit test.
*
@@ -125,21 +144,22 @@ static char *get_property(const u16 *property)
static int setup(const efi_handle_t img_handle,
const struct efi_system_table *systable)
{
- efi_uintn_t i;
+ void *acpi;
+ systemtab = systable;
boottime = systable->boottime;
- /* Find configuration tables */
- for (i = 0; i < systable->nr_tables; ++i) {
- if (!efi_st_memcmp(>tables[i].guid, _guid,
- sizeof(efi_guid_t)))
- fdt = systable->tables[i].table;
- }
+ acpi = efi_st_get_config_table(_guid);
+ fdt = efi_st_get_config_table(_guid);
+
if (!fdt) {
efi_st_error("Missing device tree\n");
return EFI_ST_FAILURE;
}
-
+ if (acpi) {
+ efi_st_error("Found ACPI table and device tree\n");
+ return EFI_ST_FAILURE;
+ }
return EFI_ST_SUCCESS;
}
@@ -183,5 +203,4 @@ EFI_UNIT_TEST(fdt) = {
.phase = EFI_EXECUTE_BEFORE_BOOTTIME_EXIT,
.setup = setup,
.execute = execute,
- .on_request = true,
};
diff --git a/test/py/tests/test_efi_selftest.py
b/test/py/tests/test_efi_selftest.py
index bc226a8e63..07e4db0452 100644
--- a/test/py/tests/test_efi_selftest.py
+++ b/test/py/tests/test_efi_selftest.py
@@ -15,7 +15,7 @@ def test_efi_selftest(u_boot_console):
This function executes all selftests that are not marked as on request.
"""
u_boot_console.run_command(cmd='setenv efi_selftest')
- u_boot_console.run_command(cmd='bootefi selftest ${fdtcontroladdr}',
wait_for_prompt=False)
+ u_boot_console.run_command(cmd='bootefi selftest',
wait_for_prompt=False)
m = u_boot_console.p.expect(['Summary: 0 failures', 'Press any key'])
if m != 0:
raise Exception('Failures occurred during the EFI selftest')
@@ -27,6 +27,7 @@ def test_efi_selftest(u_boot_console):
@pytest.mark.buildconfigspec('cmd_bootefi_selftest')
@pytest.mark.buildconfigspec('of_control')
+@pytest.mark.notbuildconfigspec('generate_acpi_table')
def test_efi_selftest_device_tree(u_boot_console):
u_boot_console.run_command(cmd='setenv efi_selftest list')
output = u_boot_console.run_command('bootefi selftest')
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/1] efi_loader: need either ACPI table or device tree
The EBBR specification prescribes that we should have either an ACPI table
or a device tree but not both. Let us enforce this condition in the
`bootefi` command.
If the bootefi command is called without a device tree parameter use a
previously device tree or fall back to the internal device tree.
The fdt unit test should not be run on boards with an ACPI table.
Signed-off-by: Heinrich Schuchardt
---
v3
The fdt unit test should not be run on boards with an ACPI table.
v2
Avoid functions defined but no used.
---
cmd/bootefi.c | 98 ---
lib/efi_selftest/Makefile | 1 -
2 files changed, 72 insertions(+), 27 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index be55751830..efaa548be4 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -84,6 +84,8 @@ out:
efi_root, NULL));
}
+#if !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
+
/**
* copy_fdt() - Copy the device tree to a new location available to EFI
*
@@ -185,6 +187,25 @@ static void efi_carve_out_dt_rsv(void *fdt)
}
}
+/**
+ * get_config_table() - get configuration table
+ *
+ * @guid: GUID of the configuration table
+ * Return: pointer to configuration table or NULL
+ */
+static void *get_config_table(const efi_guid_t *guid)
+{
+ size_t i;
+
+ for (i = 0; i < systab.nr_tables; i++) {
+ if (!guidcmp(guid, [i].guid))
+ return systab.tables[i].table;
+ }
+ return NULL;
+}
+
+#endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */
+
/**
* efi_install_fdt() - install fdt passed by a command argument
* @fdt_opt: pointer to argument
@@ -195,46 +216,71 @@ static void efi_carve_out_dt_rsv(void *fdt)
*/
static efi_status_t efi_install_fdt(const char *fdt_opt)
{
+ /*
+* The EBBR spec requires that we have either an FDT or an ACPI table
+* but not both.
+*/
+#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
+ if (fdt_opt) {
+ printf("ERROR: can't have ACPI table and device tree.\n");
+ return EFI_LOAD_ERROR;
+ }
+#else
unsigned long fdt_addr;
void *fdt;
bootm_headers_t img = { 0 };
efi_status_t ret;
if (fdt_opt) {
- /* Install device tree */
fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
- if (!fdt_addr && *fdt_opt != '0')
- return EFI_INVALID_PARAMETER;
-
- fdt = map_sysmem(fdt_addr, 0);
- if (fdt_check_header(fdt)) {
- printf("ERROR: invalid device tree\n");
+ if (!fdt_addr)
return EFI_INVALID_PARAMETER;
+ } else {
+ /* Look for device tree that is already installed */
+ if (get_config_table(_guid_fdt))
+ return EFI_SUCCESS;
+ /* Use our own device tree as default */
+ fdt_opt = env_get("fdtcontroladdr");
+ if (!fdt_opt) {
+ printf("ERROR: need device tree\n");
+ return EFI_NOT_FOUND;
}
+ fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
+ if (!fdt_addr) {
+ printf("ERROR: invalid $fdtcontroladdr\n");
+ return EFI_LOAD_ERROR;
+ }
+ }
- /* Create memory reservation as indicated by the device tree */
- efi_carve_out_dt_rsv(fdt);
+ /* Install device tree */
+ fdt = map_sysmem(fdt_addr, 0);
+ if (fdt_check_header(fdt)) {
+ printf("ERROR: invalid device tree\n");
+ return EFI_LOAD_ERROR;
+ }
- /* Prepare fdt for payload */
- ret = copy_fdt();
- if (ret)
- return ret;
+ /* Create memory reservations as indicated by the device tree */
+ efi_carve_out_dt_rsv(fdt);
- if (image_setup_libfdt(, fdt, 0, NULL)) {
- printf("ERROR: failed to process device tree\n");
- return EFI_LOAD_ERROR;
- }
+ /* Prepare device tree for payload */
+ ret = copy_fdt();
+ if (ret) {
+ printf("ERROR: out of memory\n");
+ return EFI_OUT_OF_RESOURCES;
+ }
- /* Link to it in the efi tables */
- ret = efi_install_configuration_table(_guid_fdt, fdt);
- if (ret != EFI_SUCCESS) {
- printf("ERROR: failed to install device tree\n");
- return ret;
- }
- } else {
- /* Remove device tree. EFI_NOT_FOUND can be ignored here */
- efi_install_configuration_table(_guid_fdt, NULL);
+ if (image_setup_libfdt(, fdt, 0, NULL)) {
+ printf("ERROR: failed to process device tree\n");
+
[U-Boot] Fwd: EFIBootGuard for CIP and SecureBoot
Forwarded Message Subject: Re: EFIBootGuard for CIP and SecureBoot Date: Mon, 22 Apr 2019 19:55:04 +0200 From: Heinrich Schuchardt On Fri Apr 19 10:48:51 UTC 2019 François Ozog wrote > We will be conducting a UEFI gap analysis to support EFIBootGuard in > U-Boot. > > As we are working on UEFI SecureBoot implementation in U-Boot, how do > you expect the boot process to be secured? Would U-Boot UEFI > SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will > check either grub or Linux signature? > > Please elaborate on your vision of a secured boot process. The UEFI spec is quite clear about this: An implementation of SecureBoot will check the signature of any EFI binary before starting it. StartImage() will return EFI_SECURITY_VIOLATION when trying to start an image that is neither correctly signed nor whose hash is known. As we use StartImage() for starting any image the signature of EFIBootGuard would be checked first and then any of the child applications it starts. You will not be able to start GRUB or the Linux kernel if their signature are not added to U-Boot's key database. Of cause you could implement inside EFIBootGuard your own mechanism to start a loaded image without calling StartImage(). In this case U-Boot cannot protect you from invalid images. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv4, 3/6] dm: cache: Create a uclass for cache
On Mon, Apr 01, 2019 at 05:32:17PM -0500, Dinh Nguyen wrote: > The cache UCLASS will be used for configure settings that can be found > in a CPU's L2 cache controller. > > Add a uclass and a test for cache. > > Reviewed-by: Simon Glass > Signed-off-by: Dinh Nguyen > --- > v4: re-order includes and add Reviewed-by: > v3: Add cache_get_info() to check for non-zero value > Add comments to cache_info struct > v2: separate out uclass patch from driver and add test NAK: sandbox: + tools-only +(tools-only) In file included from drivers/cache/sandbox_cache.c:6:0: +(tools-only) include/cache.h:13:2: error: unknown type name 'phys_addr_t' +(tools-only) phys_addr_t base; /* Base physical address of cache device. */ +(tools-only) ^~~ +(tools-only) int (*get_info)(struct udevice *dev, struct cache_info *info); +(tools-only) ^~~ +(tools-only) int cache_get_info(struct udevice *dev, struct cache_info *info); +(tools-only)^~~ +(tools-only) .get_info = sandbox_get_info, +(tools-only) ^~~~ +(tools-only) drivers/cache/sandbox_cache.c:21:14: note: (near initialization for 'sandbox_cach e_ops.get_info') +(tools-only) make[3]: *** [drivers/cache/sandbox_cache.o] Error 1 +(tools-only) make[2]: *** [drivers/cache] Error 2 +(tools-only) make[1]: *** [drivers] Error 2 +(tools-only) make: *** [sub-make] Error 2 w+(tools-only) include/cache.h:24:25: warning: 'struct udevice' declared inside parameter list will not be visible outside of this definition or declaration w+(tools-only) include/cache.h:36:27: warning: 'struct udevice' declared inside parameter list will not be visible outside of this definition or declaration w+(tools-only) drivers/cache/sandbox_cache.c:21:14: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fit: Add support for printing more than one FPGA node name
On Wed, Feb 13, 2019 at 08:32:24PM +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> This would print out all the FPGA node names setting to fpga property.
>
> Signed-off-by: Tien Fong Chee
> ---
> common/image-fit.c | 14 +++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index ac901e1..816e17d 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -263,6 +263,7 @@ static void fit_conf_print(const void *fit, int noffset,
> const char *p)
> int ret;
> int fdt_index, loadables_index;
> int ndepth;
> + ulong count;
>
> /* Mandatory properties */
> ret = fit_get_desc(fit, noffset, );
> @@ -299,9 +300,16 @@ static void fit_conf_print(const void *fit, int noffset,
> const char *p)
> printf("%s\n", uname);
> }
>
> - uname = fdt_getprop(fit, noffset, FIT_FPGA_PROP, NULL);
> - if (uname)
> - printf("%s FPGA: %s\n", p, uname);
> + count = fit_conf_get_prop_node_count(fit, noffset, FIT_FPGA_PROP);
> +
> + for (ndepth = 0; ndepth < count; ndepth++) {
> + int images_noffset = fit_conf_get_prop_node_index(fit, noffset,
> + FIT_FPGA_PROP, ndepth);
> + uname = fit_get_name(fit, images_noffset, NULL);
> +
> + if (uname)
> + printf("%s FPGA: %s\n", p, uname);
> + }
>
> /* Print out all of the specified loadables */
> for (loadables_index = 0;
While I'm fine with the conceptual change here, both
fit_conf_get_prop_node_count / fit_conf_get_prop_node_index are defined
later in the file and while public functions not documented in a header.
Can you please do a patch that does so first, as we otherwise get a
warning? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] spl: avoid printf when we might be doing Ymodem with CONFIG_SPL_FIT_SIGNATURE
On Mon, Apr 22, 2019 at 06:40:33PM +0200, Marek Vasut wrote:
> On 4/22/19 6:12 PM, Tom Rini wrote:
> > On Wed, Mar 20, 2019 at 07:52:20PM +, Alex Kiernan wrote:
> >> If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
> >> over Ymodem then we can't emit messages using printf() without causing
> >> errors like:
> >>
> >> Sending: u-boot-dtb.img
> >> Ymodem sectors/kbytes sent: 3009/376kRetry 0: Got 23 for sector ACK
> >> Retry 0: NAK on sector
> >> Retry 0: Got 68 for sector ACK
> >> Retry 0: NAK on sector
> >> Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
> >> Retry 0: NAK on sector
> >> Retry 0: Got 68 for sector ACK
> >> Retry 0: NAK on sector
> >>
> >> Use debug() rather than printf() to avoid sending messages on the serial
> >> port.
> >>
> >> Signed-off-by: Alex Kiernan
> >> ---
> >>
> >> common/spl/spl_fit.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> >> index db436268cbcd..08faf2c1b058 100644
> >> --- a/common/spl/spl_fit.c
> >> +++ b/common/spl/spl_fit.c
> >> @@ -240,12 +240,12 @@ static int spl_load_fit_image(struct spl_load_info
> >> *info, ulong sector,
> >>}
> >>
> >> #ifdef CONFIG_SPL_FIT_SIGNATURE
> >> - printf("## Checking hash(es) for Image %s ... ",
> >> - fit_get_name(fit, node, NULL));
> >> + debug("## Checking hash(es) for Image %s ... ",
> >> +fit_get_name(fit, node, NULL));
> >>if (!fit_image_verify_with_data(fit, node,
> >> src, length))
> >>return -EPERM;
> >> - puts("OK\n");
> >> + debug("OK\n");
> >> #endif
> >>
> >> #ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> >
> > I think in this case we want to have that bit of "garbage" happen as the
> > protocol handles them correctly and if there is a problem it's visible
> > "on the line" to be seen at least and can be dug at. The other
> > alternative here would be to re-work the code to only printf anything on
> > the error case and debug that we're checking at all.
>
> Can we do something similar to this ?
> https://patchwork.ozlabs.org/patch/1055047/
Another valid approach, yes.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
Hi Simon,
Thanks for the review.
please see inline, I have few questions/suggestions regarding
your notes.
Thanks,
Ramon.
On Mon, Apr 22, 2019 at 5:56 AM Simon Glass wrote:
> Hi Ramon,
>
> On Fri, 5 Apr 2019 at 19:12, Ramon Fried wrote:
> >
> > Introduce new UCLASS_PCI_EP class for handling PCI endpoint
> > devices, allowing to set various attributes of the PCI endpoint
> > device, such as:
> > * configuration space header
> > * BAR definitions
> > * outband memory mapping
> > * start/stop PCI link
> >
> > Signed-off-by: Ramon Fried
> >
> > ---
> >
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 1 +
> > drivers/pci_endpoint/Kconfig | 16 ++
> > drivers/pci_endpoint/Makefile| 6 +
> > drivers/pci_endpoint/pci_ep-uclass.c | 192 ++
> > include/dm/uclass-id.h | 1 +
> > include/pci_ep.h | 375 +++
> > 7 files changed, 593 insertions(+)
> > create mode 100644 drivers/pci_endpoint/Kconfig
> > create mode 100644 drivers/pci_endpoint/Makefile
> > create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c
> > create mode 100644 include/pci_ep.h
>
> This looks pretty good but I have a lot of nits, sorry.
>
> no worries.
> Please can you add a sandbox driver and a test for this (can be in a
> separate patch).
>
> sure.
> >
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index f24351ac4f..59e2c22cc6 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -64,6 +64,8 @@ source "drivers/nvme/Kconfig"
> >
> > source "drivers/pci/Kconfig"
> >
> > +source "drivers/pci_endpoint/Kconfig"
> > +
> > source "drivers/pch/Kconfig"
> >
> > source "drivers/pcmcia/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index a7bba3ed56..480b97ef58 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -85,6 +85,7 @@ obj-$(CONFIG_FPGA) += fpga/
> > obj-y += misc/
> > obj-$(CONFIG_MMC) += mmc/
> > obj-$(CONFIG_NVME) += nvme/
> > +obj-$(CONFIG_PCI_ENDPOINT) += pci_endpoint/
> > obj-y += pcmcia/
> > obj-y += dfu/
> > obj-$(CONFIG_PCH) += pch/
> > diff --git a/drivers/pci_endpoint/Kconfig b/drivers/pci_endpoint/Kconfig
> > new file mode 100644
> > index 00..2c0a399a08
> > --- /dev/null
> > +++ b/drivers/pci_endpoint/Kconfig
> > @@ -0,0 +1,16 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# PCI Endpoint Support
> > +#
> > +
> > +menu "PCI Endpoint"
> > +
> > +config PCI_ENDPOINT
> > + bool "PCI Endpoint Support"
> > + depends on DM
> > + help
> > + Enable this configuration option to support configurable PCI
> > + endpoint. This should be enabled if the platform has a PCI
>
> s/endpoint/endpoints/ I think
>
> Right.
> > + controller that can operate in endpoint mode.
>
Can you explain a bit more about what this means. I understand that
> people can look at the spec, but what is the purpose of 'endpoint
> mode' and what does it enable?
>
> > +
> > +endmenu
> > diff --git a/drivers/pci_endpoint/Makefile
> b/drivers/pci_endpoint/Makefile
> > new file mode 100644
> > index 00..80a1066925
> > --- /dev/null
> > +++ b/drivers/pci_endpoint/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# (C) Copyright 2019
> > +# Ramon Fried
> > +
> > +obj-y += pci_ep-uclass.o
> > diff --git a/drivers/pci_endpoint/pci_ep-uclass.c
> b/drivers/pci_endpoint/pci_ep-uclass.c
> > new file mode 100644
> > index 00..06fcfc5d14
> > --- /dev/null
> > +++ b/drivers/pci_endpoint/pci_ep-uclass.c
> > @@ -0,0 +1,192 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * PCI Endpoint uclass
> > + *
> > + * Based on Linux PCI-EP driver written by
> > + * Kishon Vijay Abraham I
> > + *
> > + * Copyright (c) 2019
> > + * Written by Ramon Fried
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +int dm_pci_ep_write_header(struct udevice *dev, u8 fn,
> > + struct pci_ep_header *hdr)
> > +{
> > + struct dm_pci_ep_ops *ops = pci_ep_get_ops(dev);
> > +
> > + if (!ops->write_header)
> > + return -ENODEV;
>
> -ENOSYS (please fix globally)
>
> OK.
> There is a device. The problem here is that the driver does not
> implement the method.
>
> > +
> > + return ops->write_header(dev, fn, hdr);
> > +}
> > +
> > +int dm_pci_ep_read_header(struct udevice *dev, u8 fn,
> > + struct pci_ep_header *hdr)
> > +{
> > + struct dm_pci_ep_ops *ops = pci_ep_get_ops(dev);
> > +
> > + if (!ops->read_header)
> > + return -ENODEV;
> > +
> > + return ops->read_header(dev, fn, hdr);
> > +}
> > +
> > +int dm_pci_ep_set_bar(struct udevice *dev, u8 func_no,
>
> Please use uint for func_no. There is no need to limit it to 8 bits,
> and this may not be efficient for non-8-bit machines. Please fix
> globally.
Re: [U-Boot] spl: avoid printf when we might be doing Ymodem with CONFIG_SPL_FIT_SIGNATURE
On 4/22/19 6:12 PM, Tom Rini wrote:
> On Wed, Mar 20, 2019 at 07:52:20PM +, Alex Kiernan wrote:
>> If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
>> over Ymodem then we can't emit messages using printf() without causing
>> errors like:
>>
>> Sending: u-boot-dtb.img
>> Ymodem sectors/kbytes sent: 3009/376kRetry 0: Got 23 for sector ACK
>> Retry 0: NAK on sector
>> Retry 0: Got 68 for sector ACK
>> Retry 0: NAK on sector
>> Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
>> Retry 0: NAK on sector
>> Retry 0: Got 68 for sector ACK
>> Retry 0: NAK on sector
>>
>> Use debug() rather than printf() to avoid sending messages on the serial
>> port.
>>
>> Signed-off-by: Alex Kiernan
>> ---
>>
>> common/spl/spl_fit.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index db436268cbcd..08faf2c1b058 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -240,12 +240,12 @@ static int spl_load_fit_image(struct spl_load_info
>> *info, ulong sector,
>> }
>>
>> #ifdef CONFIG_SPL_FIT_SIGNATURE
>> -printf("## Checking hash(es) for Image %s ... ",
>> - fit_get_name(fit, node, NULL));
>> +debug("## Checking hash(es) for Image %s ... ",
>> + fit_get_name(fit, node, NULL));
>> if (!fit_image_verify_with_data(fit, node,
>> src, length))
>> return -EPERM;
>> -puts("OK\n");
>> +debug("OK\n");
>> #endif
>>
>> #ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
>
> I think in this case we want to have that bit of "garbage" happen as the
> protocol handles them correctly and if there is a problem it's visible
> "on the line" to be seen at least and can be dug at. The other
> alternative here would be to re-work the code to only printf anything on
> the error case and debug that we're checking at all.
Can we do something similar to this ?
https://patchwork.ozlabs.org/patch/1055047/
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] board: ti: am654: select SYS_DISABLE_DCACHE_OPS for arm64 build
AM654 SoC is IO coherent wrt A53 cores, therefore enable SYS_DISABLE_DCACHE_OPS to avoid cache operations in A53 SPL/U-Boot. Signed-off-by: Vignesh Raghavendra --- board/ti/am65x/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig index d4b36dbb42f3..98172c28f5d3 100644 --- a/board/ti/am65x/Kconfig +++ b/board/ti/am65x/Kconfig @@ -11,6 +11,7 @@ config TARGET_AM654_A53_EVM bool "TI K3 based AM654 EVM running on A53" select ARM64 select SOC_K3_AM6 + select SYS_DISABLE_DCACHE_OPS config TARGET_AM654_R5_EVM bool "TI K3 based AM654 EVM running on R5" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arch: armv8: Provide a way to disable cache maintenance ops
On AM654 SoC(arm64) which is IO coherent and has L3 Cache, cache
maintenance operations being done to support non-coherent platforms
causes issues.
For example, here is how U-Boot prepares/handles a buffer to receive
data from a device (DMA Write). This may vary slightly depending on the
driver framework:
Start DMA to write to destination buffer
Wait for DMA to be done (dma_receive()/dma_memcpy())
Invalidate destination buffer (invalidate_dcache_range())
Read from destination buffer
The invalidate after the DMA is needed in order to read latest data from
memory that’s updated by DMA write. Also, in case random prefetch has
pulled in buffer data during the “wait for DMA” before the DMA has
written to it. This works well for non-coherent architectures.
In case of coherent architecture with L3 cache, DMA write would directly
update L3 cache contents (assuming cacheline is present in L3) without
updating the DDR memory. So invalidate after “wait for DMA” in above
sequence would discard latest data and read will cause stale data to be
fetched from DDR. Therefore invalidate after “wait for DMA” is not
always correct on coherent architecture.
Therefore, provide a Kconfig option to disable cache maintenance ops on
coherent architectures. This has added benefit of improving the
performance of DMA transfers as we no longer need to invalidate/flush
individual cache lines(especially for buffer thats several KBs in size).
In order to facilitate use of same Kconfig across different
architecture, I have added the symbol to top level arch/Kconfig file.
Patch currently disables cache maintenance ops for arm64 only.
flush_dcache_all() and invalidate_dcache_all() are exclusively used
during enabling/disabling dcache and hence are not disabled.
Signed-off-by: Vignesh Raghavendra
---
arch/Kconfig | 9 +
arch/arm/cpu/armv8/cache_v8.c | 10 ++
2 files changed, 19 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 2f3d07c13a18..760023b19a81 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -227,6 +227,15 @@ config SYS_CONFIG_NAME
The header file include/configs/.h
should be included from include/config.h.
+config SYS_DISABLE_DCACHE_OPS
+ bool
+ help
+This option disables dcache flush and dcache invalidation
+operations. For example, on coherent systems where cache
+operatios are not required, enable this option to avoid them.
+Note that, its up to the individual architectures to implement
+this functionality.
+
source "arch/arc/Kconfig"
source "arch/arm/Kconfig"
source "arch/m68k/Kconfig"
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 038405173eb1..9ca397e73c9b 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -443,6 +443,7 @@ inline void flush_dcache_all(void)
debug("flushing dcache successfully.\n");
}
+#ifndef CONFIG_SYS_DISABLE_DCACHE_OPS
/*
* Invalidates range in all levels of D-cache/unified cache
*/
@@ -458,6 +459,15 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
{
__asm_flush_dcache_range(start, stop);
}
+#else
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+#endif /* CONFIG_SYS_DISABLE_DCACHE_OPS */
void dcache_enable(void)
{
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] Add Kconfig to disable cache ops
This series adds a Kconfig to disable cache maintenance operations on a coherent architectures. And disable cache flush/invalidate ops for SPL/U-Boot code running on A53 core of AM654 SoC(which is IO coherent) v2: Allow flush_dcache_all() and invalidate_dcache_all() that are used before enabling/disabling dcache by U-Boot and are special case. Vignesh Raghavendra (2): arch: armv8: Provide a way to disable cache maintenance ops board: ti: am654: select SYS_DISABLE_DCACHE_OPS for arm64 build arch/Kconfig | 9 + arch/arm/cpu/armv8/cache_v8.c | 10 ++ board/ti/am65x/Kconfig| 1 + 3 files changed, 20 insertions(+) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: Update env_addr for mmc environment driver
On Mon, Mar 18, 2019 at 06:16:55AM +, Pankit Garg wrote:
> Signed-off-by: Pankit Garg
> ---
> Changes for v2:
> - Remove CRC calculation as it is already part of env_import
> - Update env_addr after env_import
>
> env/mmc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index c3cf35d..d329bea 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -313,6 +313,7 @@ static int env_mmc_load(void)
> int ret;
> int dev = mmc_get_env_dev();
> const char *errmsg;
> + env_t *ep = NULL;
>
> mmc = find_mmc_device(dev);
>
> @@ -334,6 +335,10 @@ static int env_mmc_load(void)
> }
>
> ret = env_import(buf, 1);
> + if (!ret) {
> + ep = (env_t *)buf;
> + gd->env_addr= (ulong)&(ep->data);
> + }
>
> fini:
> fini_mmc_for_env(mmc);
Do we need to update the redundant env location section of code with
this too?
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] spl: avoid printf when we might be doing Ymodem with CONFIG_SPL_FIT_SIGNATURE
On Wed, Mar 20, 2019 at 07:52:20PM +, Alex Kiernan wrote:
> If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
> over Ymodem then we can't emit messages using printf() without causing
> errors like:
>
> Sending: u-boot-dtb.img
> Ymodem sectors/kbytes sent: 3009/376kRetry 0: Got 23 for sector ACK
> Retry 0: NAK on sector
> Retry 0: Got 68 for sector ACK
> Retry 0: NAK on sector
> Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
> Retry 0: NAK on sector
> Retry 0: Got 68 for sector ACK
> Retry 0: NAK on sector
>
> Use debug() rather than printf() to avoid sending messages on the serial
> port.
>
> Signed-off-by: Alex Kiernan
> ---
>
> common/spl/spl_fit.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index db436268cbcd..08faf2c1b058 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -240,12 +240,12 @@ static int spl_load_fit_image(struct spl_load_info
> *info, ulong sector,
> }
>
> #ifdef CONFIG_SPL_FIT_SIGNATURE
> - printf("## Checking hash(es) for Image %s ... ",
> -fit_get_name(fit, node, NULL));
> + debug("## Checking hash(es) for Image %s ... ",
> + fit_get_name(fit, node, NULL));
> if (!fit_image_verify_with_data(fit, node,
>src, length))
> return -EPERM;
> - puts("OK\n");
> + debug("OK\n");
> #endif
>
> #ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
I think in this case we want to have that bit of "garbage" happen as the
protocol handles them correctly and if there is a problem it's visible
"on the line" to be seen at least and can be dug at. The other
alternative here would be to re-work the code to only printf anything on
the error case and debug that we're checking at all.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
On Fri, Apr 12, 2019 at 12:32:12PM -0400, Robert P. J. Day wrote:
>
> only a few months ago, i jumped into a discussion regarding Kbuild
> config options that were defined in some Kconfig* file, but were
> unused anywhere in the source tree:
>
> http://u-boot.10912.n7.nabble.com/policy-regarding-unused-code-td351802.html#a351835
>
> many years ago, i wrote a script to locate such entries in the linux
> kernel source tree and, once u-boot adoopted the Kbuild build system,
> i could obviously use the same script on the u-boot source -- so far,
> so good. but i wrote some associated scripts to locate other oddities,
> and one of them was to find what i called "badref" options.
>
> now, "unused" options are typically not serious -- a Kbuild option
> is defined that is simply not tested anywhere in the source. normally,
> that's because someone removed some source and just forgot to remove
> the associated Kconfig option.
>
> "badref" options, on the other hand, are exactly the opposite --
> options that *are* tested somewhere in the code, but are not defined
> anywhere in a Kconfig file. in short, the code is testing some
> CONFIG_* option that will never, ever succeed as it isn't defined,
> which should typically be treated as a potentially more serious issue.
>
> i wrote up an example of this here:
>
> https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_badref
>
> where you can see the result of running the script and asking it to
> scan the entire u-boot "drivers" directory once upon a time -- the
> output consists of a string for which the corresponding
> CONFIG_ is being tested somewhere in the argument directory,
> but for which there is no apparent Kconfig definition; the output for
> each string consists of a tree-wide search for that string.
>
> as an example, note the very first example found:
>
> > ACX517AKN
> drivers/video/pxa_lcd.c:201:#ifdef CONFIG_ACX517AKN
> drivers/video/pxa_lcd.c:231:#endif /* CONFIG_ACX517AKN */
> drivers/video/pxa_lcd.c:297:#endif /* CONFIG_ACX517AKN */
> scripts/config_whitelist.txt:15:CONFIG_ACX517AKN
>
> so CONFIG_ACX517AKN is clearly being tested, while there is no
> definition for that option *anywhere* in the tree. (the script might
> not be perfect, there might be the occasional false negative or
> positive, but one can always verify manually if there's any doubt.)
>
> one of the worst culprits appears to be CONFIG_SPL_BUILD, which
> appears all over the tree, but one can see a recent commit that takes
> that into account:
>
> commit 0ef692084363f2de8547db93397c6a69123d26ca
> Author: Baruch Siach
> Date: Thu Feb 7 13:21:16 2019 +0200
>
> Kconfig: fix BUILD_TARGET for ARCH_MVEBU
>
> Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
> mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
> there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
> fix that.
>
> Cc: Jagan Teki
> Signed-off-by: Baruch Siach
> Reviewed-by: Stefan Roese
> Reviewed-by: Jagan Teki
> Signed-off-by: Stefan Roese
So, we have two different problems here. One of which, as shown by
CONFIG_ACX517AKN is symbols that need to be migrated to Kconfig but also
likely weren't ever added with something setting the option true (or, if
you dig you might see the board(s) that used that option were dropped,
but that bit of code was not). The second of which is things like
CONFIG_SPL_BUILD / CONFIG_TPL_BUILD that are not to be used in Kconfig
but are used in Kbuild as we set that as makes sense for the stage of
the build.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board_f: Do not mark pre-relocated fdt space as reserved
On Thu, Apr 18, 2019 at 08:23:45AM +0200, Simon Goldschmidt wrote:
> On Thu, Apr 18, 2019 at 8:12 AM Lokesh Vutla wrote:
> >
> >
> >
> > On 18/04/19 12:46 AM, Simon Goldschmidt wrote:
> > > [This is a follow-up to https://patchwork.ozlabs.org/patch/1033584/
> > > right?]
> >
> > Right.
> >
> > >
> > > Am 16.04.2019 um 10:43 schrieb Lokesh Vutla:
> > >> SPL while copying u-boot and dtb it does the following:
> > >> - Copy u-boot
> > >> - Copy right dtb.
> > >> - mark dtb location as reserved in dtb.
> > >
> > > Hmm, why does it do that? Reserving space when U-Boot starts Linux
> > > *might* make
> > > sense, but why should SPL add this reservation when starting U-Boot?
> > > These steps
> > > are for U-Boot in a fit-image, right? Because I can't see this for U-Boot
> > > as
> > > uImage.
> > >
> > > Am I correct that 'fdt_shrink_to_minimum()' adds this reservation? The
> > > name of
> > > that function doesn't suggest that to me. Would it make more sense to let
> > > this
> > > funtion only *change* the reservation, i.e. only add it if it is removed
> > > at the
> > > beginning of said function? Would that fix your issue?
> > >
> > > Something like this:
> > >
> > > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > > index ab08a0114f..4e7cf6ebe9 100644
> > > --- a/common/fdt_support.c
> > > +++ b/common/fdt_support.c
> > > @@ -597,6 +597,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
> > > uint64_t addr, size;
> > > int total, ret;
> > > uint actualsize;
> > > + int fdt_memrsv = 0;
> > >
> > > if (!blob)
> > > return 0;
> > > @@ -606,6 +607,7 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
> > > fdt_get_mem_rsv(blob, i, , );
> > > if (addr == (uintptr_t)blob) {
> > > fdt_del_mem_rsv(blob, i);
> > > + fdt_memrsv = 1;
> > > break;
> > > }
> > > }
> > > @@ -627,10 +629,12 @@ int fdt_shrink_to_minimum(void *blob, uint
> > > extrasize)
> > > /* Change the fdt header to reflect the correct size */
> > > fdt_set_totalsize(blob, actualsize);
> > >
> > > - /* Add the new reservation */
> > > - ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
> > > - if (ret < 0)
> > > - return ret;
> > > + if (fdt_memrsv) {
> > > + /* Add the new reservation */
> > > + ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob),
> > > actualsize);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> >
> > Agreed. This works and more appropriate place to fix it. Will you post a
> > separate patch or do you want me to post it on your behalf?
>
> While it's good to know this fixes your issue, I'm not sure this doesn't break
> anything else.
>
> Tom, Simon, can you add anything here? Why is the dtb memory added as
> reserved to itself? It seems to me this is redundant, as the code using the
> dtb should well know the pointer to it...
>
> Lokesh, I can send a patch once this is discussed.
OK, so the history of that call is really what's seen in:
commit 41c5eaa7253ed82bbae1eda5667755872c615164
Author: Andy Fleming
Date: Mon Jun 16 13:58:56 2008 -0500
Resize device tree to allow space for board changes and the chosen node
Current code requires that a compiled device tree have space added to the
end to
leave room for extra nodes added by board code (and the chosen node). This
requires that device tree creators anticipate how much space U-Boot will
add to
the tree, which is absurd. Ideally, the code would resize and/or relocate
the
tree when it needed more space, but this would require a systemic change to
the
fdt code, which is non-trivial. Instead, we resize the tree inside
boot_relocate_fdt, reserving either the remainder of the bootmap (in the
case
where the fdt is inside the bootmap), or adding CFG_FDT_PAD bytes to the
size.
Signed-off-by: Andy Fleming
Which is all about preparing things for passing the device tree we
loaded specifically for Linux. In:
commit 3082d2348c8e13342f5fdd10e9b3f7408062dbf9
Author: Kumar Gala
Date: Fri Aug 15 08:24:42 2008 -0500
fdt: refactor fdt resize code
Move the fdt resizing code out of ppc specific boot code and into
common fdt support code.
Signed-off-by: Kumar Gala
The code was moved to a more common area. So the intent on "reserve"
was to make sure that we had enough space set aside for the dtb to be
able to be updated at runtime, by U-Boot, for various needs and that we
wouldn't give that memory away to something else / allow it to be
clobbered.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Is mmc still being actively maintained?
On 4/22/19 3:40 PM, Tom Rini wrote: > On Mon, Apr 22, 2019 at 05:09:45AM +, Peng Fan wrote: >> Hi Lukasz, >> >>> Subject: Re: [U-Boot] Is mmc still being actively maintained? >>> >>> Hi Peng, >>> Hi All, Jaehoon Is mmc still being actively maintained? >>> >>> As fair as I can tell, it is "maintained" by Tom and Marek as last PR by >>> Jaehoon >>> has been sent on: >>> Tue, 8 May 2018 16:22:14 +0900 >>> I would help if it is not being maintained. >>> >>> It would be great if you could help with maintaining this code as a >>> dedicated >>> Custodian. >> >> If no one maintaining this code, I could be a dedicated custodian to collect >> patches >> if no objections. > > That would be greatly appreciated! Off-list can you please send me and > Wolfgang an SSH key and let us know what your patchwork username is? I'm also for a new MMC maintainer, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
On Thu, Apr 18, 2019 at 10:12:36PM +0200, Simon Goldschmidt wrote: > Heinrich, > > On 02.04.19 19:19, Heinrich Schuchardt wrote: > >The SPL image for the Tinker Board has to fit into 32 KiB. This includes > >up to 2 KiB for the file header. > > > >A new configuration variable CONFIG_SPL_SIZE_LIMIT is introduced to define > >the board specific limit. > > > >A common Makefile function is used for this test and the test against > >CONFIG_BOARD_SIZE_LIMIT. > > > >Move the board size check from arch/arm/mach-imx/Makefile to Makefile. > > Has anything from this series been applied? I now have a working patch that > applies on top of this and adds a full SPL SRAM size check (including HEAP, > GD and stack; via a host tool) which works for socfpga (as an example of a > platform where SPL binary is loaded to limited SRAM). > > Actually, my patch would replace your patch 3/4 but build on 1/4 (2/4 and > 4/4 are arch-specific). > > How should we proceed here? I could send a series including your 1/4, or I > could send a series completely building on this series, at the downside of > more or less reverting your 2/4. What I would like to see is i.MX (and rockchip) converted to use your new test as well (also, yay! Thanks for following up on that!) and we drop the existing check here. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/13] m68k: add basic set of devicetrees
On Fri, Apr 19, 2019 at 12:10:39PM +0530, Jagan Teki wrote: > Hi Angelo, > > On Thu, Mar 14, 2019 at 2:17 AM Angelo Dureghello wrote: > > > > This patch adds a basic group of devicetrees, one for each > > cpu family, including actually just uart and dspi devices, > > since these are the drivers supporting devicetree (support > > added in this patch-set). > > > > Acked-by: Jagan Teki > > Signed-off-by: Angelo Dureghello > > --- > > Any chance to apply this series? I fine with spi dm conversion. merge > it asap, before MW. > > Reviewed-by: Jagan Teki Yes, do you expect to have an m68k PR soon? I think the series you've been working on is certainly stable enough to pull in and work on top of as needed, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Fri, Apr 19, 2019 at 08:52:28AM +, Peng Fan wrote: > > > On Fri, 19 Apr 2019 11:56:25 +0530 > > Jagan Teki wrote: > > > > > On Fri, Apr 5, 2019 at 2:20 AM Lukasz Majewski wrote: > > > > > > > > Hi Jagan, > > > > > > > > > On Thu, Apr 4, 2019 at 3:31 PM Lukasz Majewski > > > > > wrote: > > > > > > > > > > > > On Thu, 4 Apr 2019 14:56:36 +0530 Jagan Teki > > > > > > wrote: > > > > > > > > > > > > > On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, 2 Apr 2019 16:58:33 +0530 Jagan Teki > > > > > > > > wrote: > > > > > > > > > > > > > > > > > This is revised version of previous i.MX6 clock management > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > The main difference between previous version is > > > > > > > > > - Group the i.MX6 ccm clocks into gates and tree instead > > > > > > > > > of handling the clocks in simple way using case statement. > > > > > > > > > - use gate clocks for enable/disable management. > > > > > > > > > - use tree clocks for get/set rate or parent traverse > > > > > > > > > management. > > > > > > > > > - parent clock handling via clock type. > > > > > > > > > - traverse the parent clock using recursive functionlaity. > > > > > > > > > > > > > > > > > > The main motive behind this tree framework is to make the > > > > > > > > > clock tree management simple and useful for U-Boot > > > > > > > > > requirements instead of garbing Linux clock management > > > > > > > > > code. > > > > > > > > > > > > > > > > > > We are trying to manage the Allwinner clocks with similar > > > > > > > > > kind, so having this would really help i.MX6 as well. > > > > > > > > > > > > > > > > > > Added simple names for clock macros, but will update it in > > > > > > > > > future version. > > > > > > > > > > > > > > > > > > I have skipped ENET clocks from previous series, will add > > > > > > > > > it in future patches. > > > > > > > > > > > > > > > > > > Changes for v2: > > > > > > > > > - changed framework patches. > > > > > > > > > - add support for imx6qdl and imx6ul boards > > > > > > > > > - add clock gates, tree. > > > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > > > > > > > > > > > > > > > Any inputs? > > > > > > > > > > > > > > > > Hmm It looks like we are doing some development in > > > > > > > > parallel. > > > > > > > > > > > > > > > > Please look into following commit [1]: > > > > > > > > https://patchwork.ozlabs.org/patch/1034051/ > > > > > > > > > > > > > > > > It ports from Linux 5.0 the CCF framework for iMX6Q, which > > > > > > > > IMHO in the long term is a better approach. > > > > > > > > The code is kept simple and resembles the code from Barebox. > > > > > > > > > > > > > > > > Please correct me if I'm wrong, but the code from your work > > > > > > > > is not modeling muxes, gates and other components from Linux > > > > > > > > CCF. > > > > > > > > > > > > > > The U-Boot implementation of CLK would require as minimal and > > > > > > > simple as possible due to requirement of U-Boot itself. Hope > > > > > > > you agree this point? > > > > > > > > > > > > Now i.MX6 is using clock.c CLK implementation. If we decide to > > > > > > replace it - we shall do it in a way, which would allow us to > > > > > > follow Linux kernel. (the barebox implementation is a stripped > > > > > > CCF from Linux, the same is in patch [1]). > > > > > > > > > > > > > if yes having CCF stack code to handle all clock with > > > > > > > respective separate drivers management is may not require as > > > > > > > of now, IMHO. > > > > > > > > > > > > I do have a gut feeling, that we will end up with the need to > > > > > > have the CCF framework ported anyway. As for example imx7/8 can > > > > > > re-use muxes, gates code. > > > > > > > > > > As per my experience the main the over-ahead to handle clocks in > > > > > U-Boot if we go with separate clock drivers is for Video and > > > > > Ethernet peripherals. these are key IP's which use more clocks > > > > > from U-Boot point-of-view, others can be handle pretty > > > > > straight-forward unless if they don't have too much tree chain. > > > > > > > > > > On this series, the tree management is already supported ENET in > > > > > i.MX6, and Allwinner platforms. > > > > > > > > > > As of now, I'm thinking I can handle reset of the clocks with > > > > > similar way. > > > > > > > > But this code also supports ENET and ESDHCI clocks on i.MX6Q (as > > > > supporting those was the motivator for this work). > > > > > > > > One important thing to be aware of - the problem with SPL's > > > > footprint. The implementation with clock.c is small and simple, but > > > > doesn't scale well. > > > > > > > > > > > > > > > > > > > > > However, those are only my "feelings" after a glimpse look - I > > > > > > will look into your code more thoroughly and provide feedback. > > > > > > > > > > Please have a look, if possible check even the code size by adding > > > > >
Re: [U-Boot] [PATCH 1/2] pci: Add boundary check for hose->regions
On Tue, Apr 16, 2019 at 06:30:53PM +0200, Thierry Reding wrote: > On Fri, Mar 15, 2019 at 04:32:32PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > Make sure that we don't overflow the hose->regions array, otherwise we > > would end up overwriting the hose->region_count field and cause mayhem > > to ensue. Also print an error message when we'd be overflowing because > > it indicates that there aren't enough regions available and the number > > needs to be increased. > > > > Signed-off-by: Thierry Reding > > --- > > drivers/pci/pci-uclass.c | 5 + > > 1 file changed, 5 insertions(+) > > Hi Tom, > > have you had a chance to look at these two patches? Simon's reviewed > them and they are needed to restore PCI support on Jetson TX2 (P2771). They're on my list, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Is mmc still being actively maintained?
On Mon, Apr 22, 2019 at 05:09:45AM +, Peng Fan wrote: > Hi Lukasz, > > > Subject: Re: [U-Boot] Is mmc still being actively maintained? > > > > Hi Peng, > > > > > Hi All, Jaehoon > > > > > > Is mmc still being actively maintained? > > > > As fair as I can tell, it is "maintained" by Tom and Marek as last PR by > > Jaehoon > > has been sent on: > > Tue, 8 May 2018 16:22:14 +0900 > > > > > I would help if it is not > > > being maintained. > > > > It would be great if you could help with maintaining this code as a > > dedicated > > Custodian. > > If no one maintaining this code, I could be a dedicated custodian to collect > patches > if no objections. That would be greatly appreciated! Off-list can you please send me and Wolfgang an SSH key and let us know what your patchwork username is? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Sun, Apr 21, 2019 at 09:39:25PM +0200, Marek Vasut wrote: > The following changes since commit 1f4ae66eaab29bfb5d1eb44996f7826c9cd01ed1: > > Merge tag 'arc-for-2019.07' of git://git.denx.de/u-boot-arc > (2019-04-18 12:12:16 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 7fd9f31c6bd13609da61b985cf8f5f65ebebd913: > > usb: dwc2: fix gadget disconnect (2019-04-21 10:26:52 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Sun, Apr 21, 2019 at 09:38:17PM +0200, Marek Vasut wrote: > The following changes since commit 75ce8c938d39bd22460be66e6bf318bd2410c17b: > > Merge tag 'u-boot-imx-20190415' of git://git.denx.de/u-boot-imx > (2019-04-15 07:31:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to e09c1a133155724d3369e150f3ab7b63c875101c: > > timer: dw-apb: Add missing 64bit up-conversion (2019-04-17 22:20:18 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] Set environment location to ENVL_NOWHERE with CONFIG_ENV_IS_NOWHERE.
Hi, arch/arm/cpu/armv8/fsl-layerscape/cpu.c uses ENVL_NOWHERE to initialize the env_loc enum variable. Shall the ENVL_NOWHERE be replaced with ENV_NOWHERE in commit message. Regards Udit Agarwal > -Original Message- > From: Prabhakar Kushwaha > Sent: Friday, March 22, 2019 4:32 PM > To: Udit Agarwal ; u-boot@lists.denx.de > Cc: Ruchika Gupta ; Jaiprakash Singh > ; Arun Pathak > Subject: RE: [PATCH v2 1/1] Set environment location to ENVL_NOWHERE with > CONFIG_ENV_IS_NOWHERE. > > > > -Original Message- > > From: Udit Agarwal > > Sent: Thursday, March 7, 2019 2:55 PM > > To: u-boot@lists.denx.de > > Cc: Prabhakar Kushwaha ; Ruchika Gupta > > ; Jaiprakash Singh ; > > Arun Pathak ; Udit Agarwal > > Subject: [PATCH v2 1/1] Set environment location to ENVL_NOWHERE with > > CONFIG_ENV_IS_NOWHERE. > > > > ENVL_NOWHERE is dependent on CONFIG_ENV_IS_NOWHERE and not on > > CONFIG_CHAIN_OF_TRUST so return ENVL_NOWHERE when > > CONFIG_ENV_IS_NOWHERE is enabled > > > > Signed-off-by: Udit Agarwal > > --- > > S /ENVL /ENV > > --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] common: fdt_support: Check mtdparts cell size
On 4/21/19 10:33 PM, Simon Glass wrote:
Hi Stefan,
On Fri, 12 Apr 2019 at 02:46, Stefan Mavrodiev wrote:
When using fdt_fixup_mtdparts() offset and length cell sizes
are limited to 4 bytes (1 cell). However if the mtd device is
bigger then 4GiB, then #address-cells and #size-cells are
8 bytes (2 cells) [1].
This patch read #size-cells and uses either fdt32_t or
fdt64_t cell size. The default is fdt32_t.
[1] Documentation/devicetree/bindings/mtd/partition.txt
Signed-off-by: Stefan Mavrodiev
---
common/fdt_support.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 42583e3ed8..b0501e12e6 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -724,11 +724,6 @@ int fdt_increase_size(void *fdt, int add_len)
#include
#include
-struct reg_cell {
- unsigned int r0;
- unsigned int r1;
-};
-
static int fdt_del_subnodes(const void *blob, int parent_offset)
{
int off, ndepth;
@@ -787,15 +782,22 @@ int fdt_node_set_part_info(void *blob, int parent_offset,
{
struct list_head *pentry;
struct part_info *part;
- struct reg_cell cell;
int off, ndepth = 0;
int part_num, ret;
+ int sizecell;
char buf[64];
ret = fdt_del_partitions(blob, parent_offset);
if (ret < 0)
return ret;
+ /*
+* Check if size/address is 1 or 2 cells.
+* We assume #address-cells and #size-cells have same value.
+*/
+ sizecell = fdt_getprop_u32_default_node(blob, parent_offset,
+ 0, "#size-cells", 1);
+
/*
* Check if it is nand {}; subnode, adjust
* the offset in this case
@@ -844,10 +846,23 @@ add_ro:
goto err_prop;
}
- cell.r0 = cpu_to_fdt32(part->offset);
- cell.r1 = cpu_to_fdt32(part->size);
add_reg:
- ret = fdt_setprop(blob, newoff, "reg", , sizeof(cell));
+ if (sizecell == 2) {
+ fdt64_t cell[2];
+
+ cell[0] = cpu_to_fdt64(part->offset);
+ cell[1] = cpu_to_fdt64(part->size);
+ ret = fdt_setprop(blob, newoff,
+ "reg", cell, sizeof(cell));
Can you use fdt_setprop_u64() and ..._u32() instead?
Sure.
+ } else {
+ fdt32_t cell[2];
+
+ cell[0] = cpu_to_fdt32(part->offset);
+ cell[1] = cpu_to_fdt32(part->size);
+ ret = fdt_setprop(blob, newoff,
+ "reg", cell, sizeof(cell));
+ }
+
if (ret == -FDT_ERR_NOSPACE) {
ret = fdt_increase_size(blob, 512);
if (!ret)
--
2.17.1
Regards,
SImon
Best regards,
Stefan Mavrodiev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/4] rockchip: rk3399: Add Orangepi RK3399 support
Hi Steven, On Mon, Apr 22, 2019 at 2:51 PM zhaoyifan wrote: > > Hi friend, > > > > Could you please advice the the problem with RK3399 in detail? Sorry, couldn't get which issue are you talking about? Mainline u-boot work well on OrangePI, if you want to look refer the doc patch[1] or wiki[2] for more information. [1] https://patchwork.ozlabs.org/patch/1086231/ [2] https://wiki.amarulasolutions.com/bsp/rockchip/rk3399/orangepi.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: make_fit_atf: Use BL31 environ variable for file location
On Mon, Apr 22, 2019 at 8:29 AM Shyam Saini wrote:
>
> Hi Philipp, Emmanuel,
>
> On Sun, Apr 21, 2019 at 10:43 PM Jagan Teki
> wrote:
> >
> > On Tue, Feb 5, 2019 at 4:24 PM Emmanuel Vadot wrote:
> > >
> > > Other make_fit script (like imx or sunxi) use the BL31 environment
> > > variable to indicate the location of the file.
> > > Also do that for rockchip so we don't need to copy the file in the source
> > > directory.
> > >
> > > Signed-off-by: Emmanuel Vadot
> > > ---
> > > arch/arm/mach-rockchip/make_fit_atf.py | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/mach-rockchip/make_fit_atf.py
> > > b/arch/arm/mach-rockchip/make_fit_atf.py
> > > index d1faff1957..7bf58e3dd1 100755
> > > --- a/arch/arm/mach-rockchip/make_fit_atf.py
> > > +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> > > @@ -194,7 +194,7 @@ def get_bl31_segments_info(bl31_file_name):
> > >
> > > def main():
> > > uboot_elf="./u-boot"
> > > -bl31_elf="./bl31.elf"
> > > +bl31_elf=os.getenv("BL31", "./bl31.elf")
> >
> > Have similar change on my repo.
> >
> > Better through warning for non BL31 like
> >
> > if "BL31ELF" in os.environ:
> >bl31_elf=os.getenv("BL31ELF");
> >else:
> > sys.exit("ERROR: Please export BL31ELF file, check
> > board/rockchip/evb_rk3399/README)
> >
> > And BL31ELF would be proper env than BL31 since rockchip build would
> > require elf and other one has bin, IMHO.
>
> I think solution suggested by Jagan's is more generic and more useful.
> It doesn't hard code the path of bl31.elf file, instead it uses global
> BL31 environment variable.
In the AllWinner and current rk3399 devices where we use bl31 it looks
either in the root source of the root of the build output if that's
specified as part of the build process. That to me would be a minimum
as distros often build for numerous devices at once.
> If the path is hard coded then buildroot build fails for atleast
> rk3399 soc based boards because
> in buildroot it is [2] BL31=$(BINARIES_DIR)/bl31.elf, so it looks for
> bl31.elf file in binary directory
> instead of uboot directory.
>
> We encountered this build failure in recently while adding [1] RK3399
> NanoPi M4 support in buildroot.
>
> Could we consider solution suggested by Jagan while we can retain the
> variable name BL31 as is.
>
>
> [1] Buildroot thread
> http://lists.busybox.net/pipermail/buildroot/2019-April/248219.html
> [2] BL31 buildroot variable
> https://git.buildroot.net/buildroot/tree/boot/uboot/uboot.mk#n140
>
>
> Thanks a lot,
> Shyam
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-atmel-2019.07-b
Hello Tom, Please pull tag u-boot-atmel-2019.07-b , the second set of new features and fixes for u-boot-atmel for 2019.07 release. The features include the new SAMA5D2 Industrial Connectivity Platform (ICP) and some minor fixes on corvus and sam9260. Travis CI: https://travis-ci.org/ehristev/u-boot/builds/522944045 Thanks, Eugen The following changes since commit 216800acf1fbf9f498455bf3c92d4513d9a4c681: Merge branch 'master' of git://git.denx.de/u-boot-spi (2019-04-14 00:03:06 -0400) are available in the git repository at: git://git.denx.de/u-boot-atmel.git tags/u-boot-atmel-2019.07-b for you to fetch changes up to d76f093f3c3ce0260b6a9e6c39b55a672bedf560: at91: corvus_defconfig: get rid of build warnings (2019-04-22 10:17:29 +0300) Second set of u-boot-atmel features and fixes for 2019.07 cycle Eugen Hristev (1): board: atmel: add SAMA5D2 ICP board Heiko Schocher (2): at91sam9260.dtsi: add some labels at91: corvus_defconfig: get rid of build warnings Razvan Stefanescu (2): ARM: dts: at91-sama5d2-icp: Add MACB node board: sama5d2_icp: Enable MACB driver arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-sama5d2_icp-u-boot.dtsi | 30 + arch/arm/dts/at91-sama5d2_icp.dts | 132 + arch/arm/dts/at91sam9260.dtsi | 6 +- arch/arm/mach-at91/Kconfig| 12 ++ board/atmel/sama5d2_icp/Kconfig | 15 +++ board/atmel/sama5d2_icp/MAINTAINERS | 7 ++ board/atmel/sama5d2_icp/Makefile | 7 ++ board/atmel/sama5d2_icp/sama5d2_icp.c | 191 ++ configs/corvus_defconfig | 6 +- configs/sama5d2_icp_mmc_defconfig | 76 include/configs/corvus.h | 1 + include/configs/sama5d2_icp.h | 69 +++ 13 files changed, 550 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/at91-sama5d2_icp-u-boot.dtsi create mode 100644 arch/arm/dts/at91-sama5d2_icp.dts create mode 100644 board/atmel/sama5d2_icp/Kconfig create mode 100644 board/atmel/sama5d2_icp/MAINTAINERS create mode 100644 board/atmel/sama5d2_icp/Makefile create mode 100644 board/atmel/sama5d2_icp/sama5d2_icp.c create mode 100644 configs/sama5d2_icp_mmc_defconfig create mode 100644 include/configs/sama5d2_icp.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] board_r: Detect ifc-nor flash at run-time
CONFIG_MTD_NOR_FLASH flag needs to be enable for all
boot sources,as all flash drivers need to compile in
TFA Boot.Probe ifc nor flash only when there is nor
flash available on board.So needs to detect ifc-nor
flash at run-time for probing.
Signed-off-by: Pankit Garg
---
changes for v2:
- change commit id subject
common/board_r.c | 8
1 file changed, 8 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 472987d..681379c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -327,11 +327,19 @@ static int initr_manual_reloc_cmdtable(void)
#endif
#if defined(CONFIG_MTD_NOR_FLASH)
+__weak int is_flash_available(void)
+{
+ return 1;
+}
+
static int initr_flash(void)
{
ulong flash_size = 0;
bd_t *bd = gd->bd;
+ if (!is_flash_available())
+ return 0;
+
puts("Flash: ");
if (board_flash_wp_on())
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: lx2160ardb: invert AQR107 pins polarity
AQR107 PHYs interrupt pins are active-low, while the GIC expects a
level-high signal.
Signed-off-by: Florin Chiculita
---
board/freescale/lx2160a/lx2160a.c | 8
include/configs/lx2160ardb.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index b763f6d..fa4520b 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -461,12 +461,20 @@ unsigned long get_board_ddr_clk(void)
int board_init(void)
{
+#if defined(CONFIG_FSL_MC_ENET) && defined(CONFIG_TARGET_LX2160ARDB)
+ u32 __iomem *irq_ccsr = (u32 __iomem *)ISC_BASE;
+#endif
#ifdef CONFIG_ENV_IS_NOWHERE
gd->env_addr = (ulong)_environment[0];
#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+#if defined(CONFIG_FSL_MC_ENET) && defined(CONFIG_TARGET_LX2160ARDB)
+ /* invert AQR107 IRQ pins polarity */
+ out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR107_IRQ_MASK);
+#endif
+
#ifdef CONFIG_FSL_CAAM
sec_init();
#endif
diff --git a/include/configs/lx2160ardb.h b/include/configs/lx2160ardb.h
index 7acd93c..31dd43d 100644
--- a/include/configs/lx2160ardb.h
+++ b/include/configs/lx2160ardb.h
@@ -60,6 +60,7 @@
#define AQR107_PHY_ADDR1 0x04
#define AQR107_PHY_ADDR2 0x05
+#define AQR107_IRQ_MASK0x0C
#define CORTINA_NO_FW_UPLOAD
#define CORTINA_PHY_ADDR1 0x0
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ddr: imx8m: hide i.MX8M DDR options from device driver entry
Use one menu to hide the several i.MX8M DDR options from device driver entry. Signed-off-by: Peng Fan --- drivers/ddr/imx/imx8m/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/drivers/ddr/imx/imx8m/Kconfig b/drivers/ddr/imx/imx8m/Kconfig index 71f466f5ec..a83b0f43d7 100644 --- a/drivers/ddr/imx/imx8m/Kconfig +++ b/drivers/ddr/imx/imx8m/Kconfig @@ -1,3 +1,6 @@ +menu "i.MX8M DDR controllers" + depends on ARCH_IMX8M + config IMX8M_DRAM bool "imx8m dram" @@ -20,3 +23,4 @@ config SAVED_DRAM_TIMING_BASE info into memory for low power use. OCRAM_S is used for this purpose on i.MX8MM. default 0x18 +endmenu -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] test/py: pytest.mark.notbuildconfigspec()
We already can let a Python test depend on a build option being set via
@pytest.mark.buildconfigspec(). It may be necessary to let a test depend on
a build option *not* being set. So let's introduce
@pytest.mark.notbuildconfigspec
for this purpose.
Signed-off-by: Heinrich Schuchardt
---
Hello Tom,
I will introduce the patch via u-boot-efi.git.
Regards
Heinrich
---
test/py/README.md | 1 +
test/py/conftest.py | 14 +-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/test/py/README.md b/test/py/README.md
index 4d9d2b81d1..2156661d6c 100644
--- a/test/py/README.md
+++ b/test/py/README.md
@@ -310,6 +310,7 @@ instances of:
- `buildconfig.get(...`
- `@pytest.mark.buildconfigspec(...`
+- `@pytest.mark.notbuildconfigspec(...`
### Complete invocation example
diff --git a/test/py/conftest.py b/test/py/conftest.py
index e40cbf0ba1..00d8ef8ba9 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -460,11 +460,15 @@ def setup_buildconfigspec(item):
"""
mark = item.get_marker('buildconfigspec')
-if not mark:
-return
-for option in mark.args:
-if not ubconfig.buildconfig.get('config_' + option.lower(), None):
-pytest.skip('.config feature "%s" not enabled' % option.lower())
+if mark:
+for option in mark.args:
+if not ubconfig.buildconfig.get('config_' + option.lower(), None):
+pytest.skip('.config feature "%s" not enabled' %
option.lower())
+notmark = item.get_marker('notbuildconfigspec')
+if notmark:
+for option in notmark.args:
+if ubconfig.buildconfig.get('config_' + option.lower(), None):
+pytest.skip('.config feature "%s" enabled' % option.lower())
def tool_is_in_path(tool):
for path in os.environ["PATH"].split(os.pathsep):
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: corvus_defconfig: get rid of build warnings
On 15.04.2019 14:53, Heiko Schocher wrote: > fix CONFIG_OF_EMBED and add CONFIG_DM_USB > build warnings. > > Signed-off-by: Heiko Schocher > --- Applied to u-boot-atmel/master, thanks ! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: make_fit_atf: Use BL31 environ variable for file location
Hi Philipp, Emmanuel,
On Sun, Apr 21, 2019 at 10:43 PM Jagan Teki wrote:
>
> On Tue, Feb 5, 2019 at 4:24 PM Emmanuel Vadot wrote:
> >
> > Other make_fit script (like imx or sunxi) use the BL31 environment
> > variable to indicate the location of the file.
> > Also do that for rockchip so we don't need to copy the file in the source
> > directory.
> >
> > Signed-off-by: Emmanuel Vadot
> > ---
> > arch/arm/mach-rockchip/make_fit_atf.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/make_fit_atf.py
> > b/arch/arm/mach-rockchip/make_fit_atf.py
> > index d1faff1957..7bf58e3dd1 100755
> > --- a/arch/arm/mach-rockchip/make_fit_atf.py
> > +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> > @@ -194,7 +194,7 @@ def get_bl31_segments_info(bl31_file_name):
> >
> > def main():
> > uboot_elf="./u-boot"
> > -bl31_elf="./bl31.elf"
> > +bl31_elf=os.getenv("BL31", "./bl31.elf")
>
> Have similar change on my repo.
>
> Better through warning for non BL31 like
>
> if "BL31ELF" in os.environ:
>bl31_elf=os.getenv("BL31ELF");
>else:
> sys.exit("ERROR: Please export BL31ELF file, check
> board/rockchip/evb_rk3399/README)
>
> And BL31ELF would be proper env than BL31 since rockchip build would
> require elf and other one has bin, IMHO.
I think solution suggested by Jagan's is more generic and more useful.
It doesn't hard code the path of bl31.elf file, instead it uses global
BL31 environment variable.
If the path is hard coded then buildroot build fails for atleast
rk3399 soc based boards because
in buildroot it is [2] BL31=$(BINARIES_DIR)/bl31.elf, so it looks for
bl31.elf file in binary directory
instead of uboot directory.
We encountered this build failure in recently while adding [1] RK3399
NanoPi M4 support in buildroot.
Could we consider solution suggested by Jagan while we can retain the
variable name BL31 as is.
[1] Buildroot thread
http://lists.busybox.net/pipermail/buildroot/2019-April/248219.html
[2] BL31 buildroot variable
https://git.buildroot.net/buildroot/tree/boot/uboot/uboot.mk#n140
Thanks a lot,
Shyam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board/fsl/layerscape: Modify the aliases names
when compiling dts file using DTC_FLAG='-@', the device tree compiler
reports these warnings:
Warning (alias_paths): /aliases: aliases property name must include
only lowercase and '-'
Fixed the node aliases to silence these warnings.
Signed-off-by: Pankaj Bansal
---
board/freescale/ls1043aqds/eth.c | 33 +++---
board/freescale/ls1046aqds/eth.c | 26 +++
2 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/board/freescale/ls1043aqds/eth.c b/board/freescale/ls1043aqds/eth.c
index 8763913e31..e1919d2988 100644
--- a/board/freescale/ls1043aqds/eth.c
+++ b/board/freescale/ls1043aqds/eth.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
*/
#include
@@ -161,16 +162,16 @@ void board_ft_fman_fixup_port(void *fdt, char *compat,
phys_addr_t addr,
if (fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_SGMII) {
if (port == FM1_DTSEC9) {
fdt_set_phy_handle(fdt, compat, addr,
- "sgmii_riser_s1_p1");
+ "sgmii-riser-s1-p1");
} else if (port == FM1_DTSEC2) {
fdt_set_phy_handle(fdt, compat, addr,
- "sgmii_riser_s2_p1");
+ "sgmii-riser-s2-p1");
} else if (port == FM1_DTSEC5) {
fdt_set_phy_handle(fdt, compat, addr,
- "sgmii_riser_s3_p1");
+ "sgmii-riser-s3-p1");
} else if (port == FM1_DTSEC6) {
fdt_set_phy_handle(fdt, compat, addr,
- "sgmii_riser_s4_p1");
+ "sgmii-riser-s4-p1");
}
} else if (fm_info_get_enet_if(port) ==
PHY_INTERFACE_MODE_SGMII_2500) {
@@ -191,19 +192,19 @@ void board_ft_fman_fixup_port(void *fdt, char *compat,
phys_addr_t addr,
switch (port) {
case FM1_DTSEC1:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s1_p1");
+ "qsgmii-s1-p1");
break;
case FM1_DTSEC2:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s1_p2");
+ "qsgmii-s1-p2");
break;
case FM1_DTSEC5:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s1_p3");
+ "qsgmii-s1-p3");
break;
case FM1_DTSEC6:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s1_p4");
+ "qsgmii-s1-p4");
break;
default:
break;
@@ -213,19 +214,19 @@ void board_ft_fman_fixup_port(void *fdt, char *compat,
phys_addr_t addr,
switch (port) {
case FM1_DTSEC1:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s2_p1");
+ "qsgmii-s2-p1");
break;
case FM1_DTSEC2:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s2_p2");
+ "qsgmii-s2-p2");
break;
case FM1_DTSEC5:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s2_p3");
+ "qsgmii-s2-p3");
break;
case FM1_DTSEC6:
fdt_set_phy_handle(fdt, compat, addr,
- "qsgmii_s2_p4");
+ "qsgmii-s2-p4");
break;
default:
break;
@@ -268,16 +269,16 @@ void fdt_fixup_board_enet(void *fdt)
case PHY_INTERFACE_MODE_QSGMII:
switch (mdio_mux[i]) {
case EMI1_SLOT1:
-
Re: [U-Boot] [U-Boot, 2/4] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
Hi Philipp, On Mon, Apr 22, 2019 at 12:11 AM Philipp Tomsich wrote: > > > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and > > which is U-Boot specific devicetrees binding. > > > > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot > > bindings will move it future based on the requirement. > > > > This would help to sync the devicetrees from Linux whenever required > > instead of adding specific nodes. > > > > Signed-off-by: Jagan Teki > > --- > > arch/arm/dts/rk3399-evb.dts | 1 - > > arch/arm/dts/rk3399-firefly.dts | 1 - > > arch/arm/dts/rk3399-puma.dtsi | 1 - > > arch/arm/dts/rk3399-u-boot.dtsi | 8 > > 4 files changed, 8 insertions(+), 3 deletions(-) > > create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi > > > > Reviewed-by: Philipp Tomsich I have v2 version for these changes, [1] please have a look, thanks! [1] https://patchwork.ozlabs.org/cover/1086213/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
