Re: [U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
On Thu, 2019-04-04 at 14:38 +0200, Lars Povlsen wrote: > This fixes relaction isses with the PSCI_TABLE entries in > the psci_32_table and psci_64_table. > > When using 32-bit adress pointers relocation was not being applied to > the tables, causing PSCI handlers to point to the un-relocated code > area. By using 64-bit data relocation is properly applied. The > handlers are thus in the "secure data" area, which is protected by > /memreserve/ in the FDT. > > Signed-off-by: Lars Povlsen > --- > arch/arm/cpu/armv8/psci.S | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S > index 358df8fee9..b4568cf053 100644 > --- a/arch/arm/cpu/armv8/psci.S > +++ b/arch/arm/cpu/armv8/psci.S > @@ -19,8 +19,8 @@ > > /* PSCI function and ID table definition*/ > #define PSCI_TABLE(__id, __fn) \ > - .word __id; \ > - .word __fn > + .quad __id; \ > + .quad __fn > > .pushsection ._secure.text, "ax" > > @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0) > /* Caller must put PSCI function-ID table base in x9 */ > handle_psci: > psci_enter > -1: ldr x10, [x9] /* Load PSCI function > table */ > - ubfx x11, x10, #32, #32 > - ubfx x10, x10, #0, #32 > +1: ldr x10, [x9] /* Load PSCI function > table */ > cbz x10, 3f /* If reach the > end, bail out */ > cmp x10, x0 > b.eq2f /* PSCI function found > */ > - add x9, x9, #8 /* If not match, try > next entry */ > + add x9, x9, #16 /* If not match, try > next entry */ > b 1b > > -2: blr x11 /* Call PSCI > function */ > +2: ldr x11, [x9, #8] /* Load PSCI > function */ > + blr x11 /* Call PSCI function > */ > psci_return > > 3: mov x0, #ARM_PSCI_RET_NI Hmmm...I presumed you made these changes because your relocation address for "secure" section is beyond 32bits (4GB). How your page table for MMU is being setup ? Why do you need such large address space (beyond 4GB) ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 7/9] armv8: lx2160a: enable PCIe support
Hi Prabhakar, Thanks a lot for your comments! > -Original Message- > From: Prabhakar Kushwaha > Sent: 2019年4月7日 18:53 > To: Z.q. Hou ; u-boot@lists.denx.de; > albert.u.b...@aribaud.net; Priyanka Jain ; York Sun > ; sriram.d...@nxp.com; > yamada.masah...@socionext.com; Mingkai Hu ; M.h. > Lian ; bmeng...@gmail.com > Subject: RE: [RESEND PATCHv4 7/9] armv8: lx2160a: enable PCIe support > > > > -Original Message- > > From: Z.q. Hou > > Sent: Monday, March 25, 2019 7:55 AM > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain > > ; York Sun ; > > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar > Kushwaha > > ; Mingkai Hu ; > M.h. > > Lian ; bmeng...@gmail.com > > Cc: Z.q. Hou > > Subject: [RESEND PATCHv4 7/9] armv8: lx2160a: enable PCIe support > > > > From: Hou Zhiqiang > > > > Enable the PCIe Gen4 controller driver and e1000 for LX2160ARDB and > > LX2160AQDS boards. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V4: > > - Add PCI command support > > - Enable PCIe in more LX2160A defconfigs > > > > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 5 + > > configs/lx2160aqds_tfa_defconfig | 6 ++ > > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 5 + > > configs/lx2160ardb_tfa_defconfig | 6 ++ > > 4 files changed, 22 insertions(+) > > > > > Generate defconfig using make savedefconfig Yes, will fix in next version. Thanks, Zhiqiang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 5/9] pci: ls_pcie_g4: add device tree fixups for PCI Stream IDs
Hi Prabhakar,
Thanks a lot for your coments!
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: 2019年4月7日 18:52
> To: Z.q. Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; Priyanka Jain ; York Sun
> ; sriram.d...@nxp.com;
> yamada.masah...@socionext.com; Mingkai Hu ; M.h.
> Lian ; bmeng...@gmail.com
> Subject: RE: [RESEND PATCHv4 5/9] pci: ls_pcie_g4: add device tree fixups for
> PCI Stream IDs
>
>
> > -Original Message-
> > From: Z.q. Hou
> > Sent: Monday, March 25, 2019 7:55 AM
> > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain
> > ; York Sun ;
> > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar
> Kushwaha
> > ; Mingkai Hu ;
> M.h.
> > Lian ; bmeng...@gmail.com
> > Cc: Z.q. Hou
> > Subject: [RESEND PATCHv4 5/9] pci: ls_pcie_g4: add device tree fixups
> > for PCI Stream IDs
> >
> > From: Hou Zhiqiang
> >
> > Add the infrastructure for Layerscape SoCs PCIe Gen4 controller to
> > update device tree nodes to convey SMMU stream IDs in the device tree.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V4:
> > - No change
> >
> > drivers/pci/Makefile | 3 +-
> > drivers/pci/pcie_layerscape_gen4.c | 5 -
> > drivers/pci/pcie_layerscape_gen4_fixup.c | 249
> > +++
> > 3 files changed, 251 insertions(+), 6 deletions(-) create mode
> > 100644 drivers/pci/pcie_layerscape_gen4_fixup.c
> >
> > diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
> > 7f585aad55..8ee828af6d 100644
> > --- a/drivers/pci/Makefile
> > +++ b/drivers/pci/Makefile
> > @@ -32,6 +32,7 @@ obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
> > obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
> > obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
> > obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
> > -obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o
> > +obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o \
> > + pcie_layerscape_gen4_fixup.o
> > obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
> > obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o diff --git
> > a/drivers/pci/pcie_layerscape_gen4.c
> > b/drivers/pci/pcie_layerscape_gen4.c
> > index fbe7d35911..4e0d5b168e 100644
> > --- a/drivers/pci/pcie_layerscape_gen4.c
> > +++ b/drivers/pci/pcie_layerscape_gen4.c
> > @@ -570,8 +570,3 @@ U_BOOT_DRIVER(pcie_layerscape_gen4) = {
> > .probe = ls_pcie_g4_probe,
> > .priv_auto_alloc_size = sizeof(struct ls_pcie_g4), };
> > -
> > -/* No any fixup so far */
> > -void ft_pci_setup(void *blob, bd_t *bd) -{ -} diff --git
> > a/drivers/pci/pcie_layerscape_gen4_fixup.c
> > b/drivers/pci/pcie_layerscape_gen4_fixup.c
> > new file mode 100644
> > index 00..ceeea17f19
> > --- /dev/null
> > +++ b/drivers/pci/pcie_layerscape_gen4_fixup.c
> > @@ -0,0 +1,249 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> > +/*
> > + * Copyright 2018 NXP
>
> Copyright should be now 2018-2019
>
> Check for other files also.
OK, will update the Copyright for all files.
Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 2/9] armv8: lx2160a: add MMU table entries for PCIe
Hi Prabhakar,
Thanks a lot for your comments!
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: 2019年4月7日 18:49
> To: Z.q. Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; Priyanka Jain ; York Sun
> ; sriram.d...@nxp.com;
> yamada.masah...@socionext.com; Mingkai Hu ; M.h.
> Lian ; bmeng...@gmail.com
> Subject: RE: [RESEND PATCHv4 2/9] armv8: lx2160a: add MMU table entries
> for PCIe
>
>
> > -Original Message-
> > From: Z.q. Hou
> > Sent: Monday, March 25, 2019 7:54 AM
> > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain
> > ; York Sun ;
> > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar
> Kushwaha
> > ; Mingkai Hu ;
> M.h.
> > Lian ; bmeng...@gmail.com
> > Cc: Z.q. Hou
> > Subject: [RESEND PATCHv4 2/9] armv8: lx2160a: add MMU table entries
> > for PCIe
> >
> > From: Hou Zhiqiang
> >
> > The lx2160a have up to 6 PCIe controllers and have different address
> > and size of PCIe region.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V4:
> > - No change
> >
> > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 12
>
> > arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 2 ++
> > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 14
> > +-
> > 3 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > index 978d46b32f..2805e5f6f2 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > @@ -257,6 +257,18 @@ static struct mm_region final_map[] = {
> > PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > },
> > +#endif
> > +#ifdef CONFIG_ARCH_LX2160A
>
> Request to avoid SoC name in #ifdef. Use #ifdef SYS_PCIE5_PHYS_ADDR,
Yes, will change in next version.
Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] AE350 SMP support RISC-V
Hi Bin Bin Meng 於 2019年4月4日 週四 下午9:49寫道： > > Hi Rick, > > On Wed, Apr 3, 2019 at 9:37 AM Rick Chen wrote: > > > > Hi Bin and Lukas > > > > Rick Chen 於 2019年4月2日 週二 上午9:22寫道： > > > > > > Hi Bin > > > > > > Bin Meng 於 2019年4月1日 週一 下午5:01寫道： > > > > > > > > Hi Rick, > > > > > > > > On Mon, Apr 1, 2019 at 4:29 PM Andes wrote: > > > > > > > > > > From: Rick Chen > > > > > > > > > > Changes in v3: > > > > > Patch 1 > > > > > - Rename plic_init() as enable_ipi() > > > > > - Remove PLIC_BASE_GET() from enable_ipi() > > > > > Patch 2 > > > > > - Add a space before (PLMT) > > > > > Patch 6 > > > > > - Fix some mis-alignments > > > > > - Recovery isa string of CPU1 > > > > > > > > > > Changes in v2: > > > > > - Drop patch1 and replace by simple-bus driver > > > > > - Rename nds_plic as andes_plic > > > > > - Move initialize plic to PLIC_BASE_GET() and called automatically > > > > > - Rename nds_plmt as andes_plmt > > > > > - Recovery dts isa string > > > > > > > > > > Rick Chen (7): > > > > > riscv: Add a SYSCON driver for Andestech's PLIC > > > > > riscv: Add a SYSCON driver for Andestech's PLMT > > > > > riscv: ae350: disable ATCPIT100 timer > > > > > riscv: ax25: Add platform-specific Kconfig options > > > > > riscv: ax25: Andes specific cache shall only support in M-mode > > > > > riscv: dts: ae350 support SMP > > > > > riscv: ae350: enable SMP > > > > > > > > > > > > > Looks good to me. Are you going to send PR to Tom to include SMP > > > > series in v2019.04? > > > > > > > > > > Thanks for your review. > > > But there seem have some suggestions from Lukas to be fixed. > > > After that I will send PR to Tom ASAP. > > > > > > > I have send V4 and Lukas have reviewed it. > > When I try to sync to master, I found that there seem > > have CONFIG_DEFAULT_DEVICE_TREE failures issue in u-boot.git master. > > Troy have reported it actually. But u-boot-riscv.git is fine. > > So I am not sure if I shall sync to master now. > > Or I shall wait until it has been fixed. > > > > The CONFIG_DEFAULT_DEVICE_TREE fix was reviewed by Lukas and me. I > suppose it's good to send PR now? > Yes I was on Ching-Ming festival last week. After re-sync to master and travis verification. I will send a PR right away. Thanks Rick > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] armv8: ls1028a: Add NXP LS1028A SoC support
Hi Prabhakar, > -Original Message- > From: Prabhakar Kushwaha > Sent: 2019年4月7日 17:58 > To: Andy Tang > Cc: albert.u.b...@aribaud.net; Sudhanshu Gupta ; > Harninder Rai ; Rajesh Bhagat > ; Bhaskar Upadhaya ; > u-boot@lists.denx.de; Andy Tang > Subject: RE: [PATCH 1/3 v2] armv8: ls1028a: Add NXP LS1028A SoC support > > > > -Original Message- > > From: Yuantian Tang > > Sent: Wednesday, April 3, 2019 12:48 PM > > To: Prabhakar Kushwaha > > Cc: albert.u.b...@aribaud.net; Sudhanshu Gupta > > ; Harninder Rai ; > > Rajesh Bhagat ; Bhaskar Upadhaya > > ; u-boot@lists.denx.de; Andy Tang > > > > Subject: [PATCH 1/3 v2] armv8: ls1028a: Add NXP LS1028A SoC support > > > > LS1028A processor integrates two 64-bit Arm Cortex-A72 cores with a > > GPU and LCD controller, as well as TSN-enabled Ethernet ports and a > > TSN-enabled switch with four external ports. > > The high performance Cortex-A72 cores, performing above 16,000 > > CoreMarks, combined with 2.5 Gbit Ethernet, PCI express Gen 3.0, SATA > > 3.0, USB 3.0 and Octal/Quad SPI interfaces provide capabilities for a > > number of industrial and embedded applications. The device provides > > excellent integration with the new Time-Sensitive Networking standards > > and enables a number of TSN applications > > > > Features Summary > > * Two 32/64-bit Arm v8 Cortex-A72 CPUs > > * Cache coherent interconnect fabric (CCI-400) > > * 32-bit DDR3L/DDR4 SDRAM memory controller with ECC support > > * LCD controller and DisplayPort/eDP interface > > * Graphics processing unit > > * TSN-capable Ethernet Switch with four external ports > > * Ethernet Controller (ENETC) with TSN functionality > > * Four SerDes lanes with two PLLs for high-speed peripheral interfaces > > * Additional peripheral interfaces > > * Two high-speed USB 3.0 controllers > > * Two eSDHC controllers > > * Two controller area network (FlexCAN) modules > > * supporting flexible datarate (FD) > > * Three serial peripheral interface (SPI) controllers > > * Flexible SPI interface (FlexSPI) controller > > * Eight I2C controllers > > * Six LPUARTs > > * 16550-compliant DUART > > * General Purpose IO (GPIO) > > * Eight FlexTimers/PWM controllers > > * Six asynchronous audio interface (SAI) > > * Support for hardware virtualization and partitioning enforcement > > * QorIQ platform's trust architecture 3.0 > > * Queue direct memory access controller (qDMA) > > * Enhanced direct memory access controller (eDMA) > > * Global programmable interrupt controller (GIC) > > * Arm generic timer > > * Thermal Monitor Unit (TMU) > > > > It looks to be marketing description > This patch is not supporting all above features. So update description with > whatever supported by this patch. It listed all the features SOC supports, not the features this PATCH supports. We should give a full feature list when a new soc was added. > > > > Signed-off-by: Sudhanshu Gupta > > Signed-off-by: Rai Harninder > > Signed-off-by: Rajesh Bhagat > > Signed-off-by: Bhaskar Upadhaya > > Signed-off-by: Tang Yuantian > > --- > > v2: > > - fix many issues > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 39 ++- > > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 4 + > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 3 + > > arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc | 51 > > arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 88 +++ > > arch/arm/dts/fsl-ls1028a.dtsi | 280 > + > > arch/arm/include/asm/arch-fsl-layerscape/config.h | 61 + > > .../include/asm/arch-fsl-layerscape/fsl_serdes.h | 16 ++ > > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 9 + > > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 + > > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 2 +- > > 11 files changed, 552 insertions(+), 2 deletions(-) create mode 100644 > > arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c > > create mode 100644 arch/arm/dts/fsl-ls1028a.dtsi > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > index f48481f..8ecd095 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > @@ -20,6 +20,40 @@ config ARCH_LS1012A > > select SYS_I2C_MXC_I2C2 > > imply PANIC_HANG > > > > +config ARCH_LS1028A > > + bool > > + select ARMV8_SET_SMPEN > > + select FSL_LSCH3 > > + select NXP_LSCH3_2 > > + select SYS_FSL_HAS_CCI400 > > + select SYS_FSL_SRDS_1 > > + select SYS_HAS_SERDES > > + select SYS_FSL_DDR > > + select SYS_FSL_DDR_LE > > + select SYS_FSL_DDR_VER_50 > > + select SYS_FSL_HAS_DDR3 > > + select SYS_FSL_HAS_DDR4 > > + select SYS_FSL_HAS_SEC > > + select SYS_FSL_SEC_COMPAT_5 > > + select SYS_FSL_SEC_LE > > + select FSL_TZASC_1 > > + select ARCH_EARLY_INIT_R > > + select BOARD_EARLY_INIT_F > > +
Re: [U-Boot] [EXT] [PATCH v1 2/5] arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3
> -Original Message-
> From: Marcel Ziswiler [mailto:mar...@ziswiler.com]
> Sent: 2019年4月6日 20:47
> To: u-boot@lists.denx.de
> Cc: Marcel Ziswiler ; Simon Glass
> ; Peng Fan ; Stefano Babic
> ; Fabio Estevam ; Tom Rini
> ; Anatolij Gustschin ; Albert Aribaud
>
> Subject: [EXT] [PATCH v1 2/5] arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3
>
> WARNING: This email was created outside of NXP. DO NOT CLICK links or
> attachments unless you recognize the sender and know the content is safe.
>
>
>
> From: Marcel Ziswiler
>
> Add support for lpuart1, lpuart2 and lpuart3.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> arch/arm/dts/fsl-imx8dx.dtsi | 54
>
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-imx8dx.dtsi b/arch/arm/dts/fsl-imx8dx.dtsi index
> 3b1a2a20e3..715abb413d 100644
> --- a/arch/arm/dts/fsl-imx8dx.dtsi
> +++ b/arch/arm/dts/fsl-imx8dx.dtsi
> @@ -236,6 +236,21 @@
> power-domains = <_dma>;
> wakeup-irq = <225>;
> };
> + pd_dma_lpuart1: PD_DMA_UART1 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <_dma>;
> + };
> + pd_dma_lpuart2: PD_DMA_UART2 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <_dma>;
> + };
> + pd_dma_lpuart3: PD_DMA_UART3 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <_dma>;
> + };
> };
> };
>
> @@ -402,6 +417,45 @@
> status = "disabled";
> };
>
> + lpuart1: serial@5a07 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a07 0x0 0x1000>;
> + interrupts = ;
> + clocks = < IMX8QXP_UART1_CLK>,
> +< IMX8QXP_UART1_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = < IMX8QXP_UART1_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <_dma_lpuart1>;
> + status = "disabled";
> + };
> +
> + lpuart2: serial@5a08 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a08 0x0 0x1000>;
> + interrupts = ;
> + clocks = < IMX8QXP_UART2_CLK>,
> +< IMX8QXP_UART2_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = < IMX8QXP_UART2_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <_dma_lpuart2>;
> + status = "disabled";
> + };
> +
> + lpuart3: serial@5a09 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a09 0x0 0x1000>;
> + interrupts = ;
> + clocks = < IMX8QXP_UART3_CLK>,
> +< IMX8QXP_UART3_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = < IMX8QXP_UART3_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <_dma_lpuart3>;
> + status = "disabled";
> + };
> +
> usdhc1: usdhc@5b01 {
> compatible = "fsl,imx8qm-usdhc", "fsl,imx6sl-usdhc";
> interrupt-parent = <>;
Reviewed-by: Peng Fan
> --
> 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] [PATCH v1 1/5] misc: imx8: remove duplicates from scfw api
> -Original Message- > From: Marcel Ziswiler [mailto:mar...@ziswiler.com] > Sent: 2019年4月6日 20:47 > To: u-boot@lists.denx.de > Cc: Marcel Ziswiler ; Peng Fan > ; Stefano Babic ; Fabio Estevam > ; Anatolij Gustschin ; Albert > Aribaud > Subject: [EXT] [PATCH v1 1/5] misc: imx8: remove duplicates from scfw api > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > From: Marcel Ziswiler > > Remove duplicate function declarations from the SCFW API header file. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/include/asm/arch-imx8/sci/sci.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/arm/include/asm/arch-imx8/sci/sci.h > b/arch/arm/include/asm/arch-imx8/sci/sci.h > index d1621669e2..97377697f0 100644 > --- a/arch/arm/include/asm/arch-imx8/sci/sci.h > +++ b/arch/arm/include/asm/arch-imx8/sci/sci.h > @@ -62,10 +62,6 @@ int sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t > resource, sc_pm_clk_t clk, > sc_pm_clock_rate_t *rate); int > sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, > sc_pm_clock_rate_t *rate); -int > sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, > -sc_pm_clock_rate_t *rate); > -int sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, > -sc_pm_clock_rate_t *rate); > int sc_pm_clock_enable(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, >sc_bool_t enable, sc_bool_t autog); Reviewed-by: Peng Fan > > -- > 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
Hi Heinrich,
On Mon, Apr 08, 2019 at 12:11:59AM +0200, Heinrich Schuchardt wrote:
[..]
> > + switch (bcb_cmd_get(argv[0])) {
> > + case BCB_CMD_LOAD:
> > + return bcb_load(argc, argv, , _dev, _part);
> > + case BCB_CMD_FIELD_SET:
> > + return bcb_field_set(argc, argv, , bcb_dev, bcb_part);
> > + case BCB_CMD_FIELD_CLEAR:
> > + return bcb_field_clear(argc, argv, , bcb_dev, bcb_part);
> > + case BCB_CMD_FIELD_TEST:
> > + return bcb_field_test(argc, argv, , bcb_dev, bcb_part);
> > + case BCB_CMD_FIELD_DUMP:
> > + return bcb_field_dump(argc, argv, , bcb_dev, bcb_part);
> > + case BCB_CMD_STORE:
> > + return bcb_store(argc, argv, , bcb_dev, bcb_part);
> > + default:
> > + return CMD_RET_USAGE;
> > + }
>
> Please, implement the sub-commands as described in doc/README.commands
> using the U_BOOT_CMD_MKENT macro.
Thanks for the lightning-fast reply. Will fix in v2, once hopefully
more review comments are collected.
> Best regards
>
> Heinrich
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] common: Implement A/B metadata
Hi Igor, On Sun, Apr 07, 2019 at 09:11:39PM +0200, Igor Opaniuk wrote: > Hi Eugeniu, > > Sorry for the late reply. > > Please go ahead, > I'm currently on a business trip, so I won't have access to my setup > with A/B till April 19 (so I definetely won't send any updates till > that time). > > I'll sync with the patches you're going to send. Thanks for feedback! jFTR, here is the link to the newly submitted patches making use of the same AOSP header: https://patchwork.ozlabs.org/cover/1080393/ . Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
On 4/8/19 12:02 AM, Eugeniu Rosca wrote:
> 'Bootloader Control Block' (BCB) is a well established term/acronym in
> the Android namespace which refers to a location in a dedicated raw
> (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> which is used as media for exchanging messages between Android userspace
> (particularly recovery [1]) and an Android-capable bootloader.
>
> On higher level, this allows implementing a subset of Android Bootloader
> Requirements [2], amongst which is the Android-specific bootloader
> flow [3]. Regardless how the latter is implemented in U-Boot ([3] being
> the most notorious example), reading/writing/dumping the BCB fields in
> the development process from inside the U-Boot is a convenient feature.
> Hence, make it available to the users.
>
> Some usage examples of the new command recorded on R-Car H3ULCB-KF
> ('>>>' is an overlay on top of the original console output):
>
> => bcb
> bcb - Load/set/clear/test/dump/store Android BCB fields
>
> Usage:
> bcb load - load BCB from mmc :
> bcb set - set BCB to
> bcb clear [] - clear BCB or all fields
> bcb test - test BCB against
> bcb dump - dump BCB
> bcb store- store BCB back to mmc
>
> Legend:
>- MMC device index containing the BCB partition
> - MMC partition index or name containing the BCB
> - one of {command,status,recovery,stage,reserved}
> - the binary operator used in 'bcb test':
> '=' returns true if matches the string stored in
> '~' returns true if matches a subset of 's string
>- string/text provided as input to bcb {set,test}
> NOTE: any ':' character in will be replaced by line feed
> during 'bcb set' and used as separator by upper layers
>
> => bcb dump command
> Error: BCB not loaded!
> >>> Users must specify mmc device and partition before any other call
>
> => bcb load 1 misc
> => bcb load 1 1
> >>> The two calls are equivalent (assuming "misc" has index 1)
>
> => bcb dump command
> : 62 6f 6f 74 6f 6e 63 65 2d 73 68 65 6c 6c 00 72bootonce-shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
> >>> The output is in binary/string format for convenience
> >>> The output size matches the size of inspected BCB field
> >>> (32 bytes in case of 'command')
>
> => bcb test command = bootonce-shell && echo true
> true
> => bcb test command = bootonce-shell- && echo true
> => bcb test command = bootonce-shel && echo true
> >>> The '=' operator returns 'true' on perfect match
>
> => bcb test command ~ bootonce-shel && echo true
> true
> => bcb test command ~ bootonce-shell && echo true
> true
> >>> The '~' operator returns 'true' on substring match
>
> => bcb set command recovery
> => bcb dump command
> : 72 65 63 6f 76 65 72 79 00 73 68 65 6c 6c 00 72recovery.shell.r
> 0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
> >>> The new value is NULL-terminated and stored in the BCB field
>
> => bcb set recovery "msg1:msg2:msg3"
> => bcb dump recovery
> 0040: 6d 73 67 31 0a 6d 73 67 32 0a 6d 73 67 33 00 00msg1.msg2.msg3..
> 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>> --- snip ---
> >>> Every ':' is replaced by line-feed '\n' (0xA). The latter is used
> >>> as separator between individual commands by Android userspace
>
> => bcb store
> >>> Flush/store the BCB structure to MMC
>
> [1] https://android.googlesource.com/platform/bootable/recovery
> [2] https://source.android.com/devices/bootloader
> [3] https://patchwork.ozlabs.org/patch/746835/
> ("[U-Boot,5/6] Initial support for the Android Bootloader flow")
>
> Signed-off-by: Eugeniu Rosca
> ---
> cmd/Kconfig | 17 +++
> cmd/Makefile | 1 +
> cmd/bcb.c| 347 +++
> 3 files changed, 365 insertions(+)
> create mode 100644 cmd/bcb.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 0b07b3b9d777..2c32d9b85b51 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -621,6 +621,23 @@ config CMD_ADC
> Shows ADC device info and permit printing one-shot analog converted
> data from a named Analog to Digital Converter.
>
> +config CMD_BCB
> + bool "bcb"
> + depends on MMC
> + depends on PARTITIONS
> + help
> + Read/modify/write the fields of Bootloader Control Block, usually
> + stored on the flash "misc" partition with its structure defined in:
> + https://android.googlesource.com/platform/bootable/recovery/+/master/
> + bootloader_message/include/bootloader_message/bootloader_message.h
> +
> + Some real-life use-cases include (but are not limited to):
> + - Determine the "boot reason" (and act accordingly):
> + https://source.android.com/devices/bootloader/boot-reason
> +
[U-Boot] [PATCH 1/1] efi_loader: assign HII protocols to root node
We should not install the HII protocols on every loaded image. It is sufficient to install them once on the root node. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 20 lib/efi_loader/efi_root_node.c | 20 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index b215bd7723..31d11b8678 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1569,26 +1569,6 @@ efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path, if (ret != EFI_SUCCESS) goto failure; -#if CONFIG_IS_ENABLED(EFI_LOADER_HII) - ret = efi_add_protocol(>header, - _guid_hii_string_protocol, - (void *)_hii_string); - if (ret != EFI_SUCCESS) - goto failure; - - ret = efi_add_protocol(>header, - _guid_hii_database_protocol, - (void *)_hii_database); - if (ret != EFI_SUCCESS) - goto failure; - - ret = efi_add_protocol(>header, - _guid_hii_config_routing_protocol, - (void *)_hii_config_routing); - if (ret != EFI_SUCCESS) - goto failure; -#endif - *info_ptr = info; *handle_ptr = obj; diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c index b056ba3ee8..b58d9d8c96 100644 --- a/lib/efi_loader/efi_root_node.c +++ b/lib/efi_loader/efi_root_node.c @@ -74,6 +74,26 @@ efi_status_t efi_root_node_register(void) if (ret != EFI_SUCCESS) goto failure; +#if CONFIG_IS_ENABLED(EFI_LOADER_HII) + /* Install HII string protocol */ + ret = efi_add_protocol(root, _guid_hii_string_protocol, + (void *)_hii_string); + if (ret != EFI_SUCCESS) + goto failure; + + /* Install HII database protocol */ + ret = efi_add_protocol(root, _guid_hii_database_protocol, + (void *)_hii_database); + if (ret != EFI_SUCCESS) + goto failure; + + /* Install HII configuration routing protocol */ + ret = efi_add_protocol(root, _guid_hii_config_routing_protocol, + (void *)_hii_config_routing); + if (ret != EFI_SUCCESS) + goto failure; +#endif + failure: return ret; } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: enable HII protocols by default
As the UEFI shell requires the HII protocols let's enable them by default. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/Kconfig | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 23487b8130..a6489ca534 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -38,14 +38,11 @@ config EFI_LOADER_BOUNCE_BUFFER config EFI_LOADER_HII bool "Expose HII protocols to EFI applications" depends on EFI_LOADER - default n + default y help The Human Interface Infrastructure is a complicated framework that allows UEFI applications to draw fancy menus and hook strings using a translation framework. U-Boot implements enough of its features to be able to run the UEFI - Shell, but not more than that. The code is experimental still, so - beware that your system might break with HII enabled. - - If unsure, say n. + Shell, but not more than that. -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields
'Bootloader Control Block' (BCB) is a well established term/acronym in
the Android namespace which refers to a location in a dedicated raw
(i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
which is used as media for exchanging messages between Android userspace
(particularly recovery [1]) and an Android-capable bootloader.
On higher level, this allows implementing a subset of Android Bootloader
Requirements [2], amongst which is the Android-specific bootloader
flow [3]. Regardless how the latter is implemented in U-Boot ([3] being
the most notorious example), reading/writing/dumping the BCB fields in
the development process from inside the U-Boot is a convenient feature.
Hence, make it available to the users.
Some usage examples of the new command recorded on R-Car H3ULCB-KF
('>>>' is an overlay on top of the original console output):
=> bcb
bcb - Load/set/clear/test/dump/store Android BCB fields
Usage:
bcb load - load BCB from mmc :
bcb set - set BCB to
bcb clear [] - clear BCB or all fields
bcb test - test BCB against
bcb dump - dump BCB
bcb store- store BCB back to mmc
Legend:
- MMC device index containing the BCB partition
- MMC partition index or name containing the BCB
- one of {command,status,recovery,stage,reserved}
- the binary operator used in 'bcb test':
'=' returns true if matches the string stored in
'~' returns true if matches a subset of 's string
- string/text provided as input to bcb {set,test}
NOTE: any ':' character in will be replaced by line feed
during 'bcb set' and used as separator by upper layers
=> bcb dump command
Error: BCB not loaded!
>>> Users must specify mmc device and partition before any other call
=> bcb load 1 misc
=> bcb load 1 1
>>> The two calls are equivalent (assuming "misc" has index 1)
=> bcb dump command
: 62 6f 6f 74 6f 6e 63 65 2d 73 68 65 6c 6c 00 72bootonce-shell.r
0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
>>> The output is in binary/string format for convenience
>>> The output size matches the size of inspected BCB field
>>> (32 bytes in case of 'command')
=> bcb test command = bootonce-shell && echo true
true
=> bcb test command = bootonce-shell- && echo true
=> bcb test command = bootonce-shel && echo true
>>> The '=' operator returns 'true' on perfect match
=> bcb test command ~ bootonce-shel && echo true
true
=> bcb test command ~ bootonce-shell && echo true
true
>>> The '~' operator returns 'true' on substring match
=> bcb set command recovery
=> bcb dump command
: 72 65 63 6f 76 65 72 79 00 73 68 65 6c 6c 00 72recovery.shell.r
0010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00y.r.
>>> The new value is NULL-terminated and stored in the BCB field
=> bcb set recovery "msg1:msg2:msg3"
=> bcb dump recovery
0040: 6d 73 67 31 0a 6d 73 67 32 0a 6d 73 67 33 00 00msg1.msg2.msg3..
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> --- snip ---
>>> Every ':' is replaced by line-feed '\n' (0xA). The latter is used
>>> as separator between individual commands by Android userspace
=> bcb store
>>> Flush/store the BCB structure to MMC
[1] https://android.googlesource.com/platform/bootable/recovery
[2] https://source.android.com/devices/bootloader
[3] https://patchwork.ozlabs.org/patch/746835/
("[U-Boot,5/6] Initial support for the Android Bootloader flow")
Signed-off-by: Eugeniu Rosca
---
cmd/Kconfig | 17 +++
cmd/Makefile | 1 +
cmd/bcb.c| 347 +++
3 files changed, 365 insertions(+)
create mode 100644 cmd/bcb.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0b07b3b9d777..2c32d9b85b51 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -621,6 +621,23 @@ config CMD_ADC
Shows ADC device info and permit printing one-shot analog converted
data from a named Analog to Digital Converter.
+config CMD_BCB
+ bool "bcb"
+ depends on MMC
+ depends on PARTITIONS
+ help
+ Read/modify/write the fields of Bootloader Control Block, usually
+ stored on the flash "misc" partition with its structure defined in:
+ https://android.googlesource.com/platform/bootable/recovery/+/master/
+ bootloader_message/include/bootloader_message/bootloader_message.h
+
+ Some real-life use-cases include (but are not limited to):
+ - Determine the "boot reason" (and act accordingly):
+ https://source.android.com/devices/bootloader/boot-reason
+ - Get/pass a list of commands from/to recovery:
+ https://android.googlesource.com/platform/bootable/recovery
+ - Inspect/dump the contents of the BCB fields
+
config CMD_BIND
bool "bind/unbind - Bind
[U-Boot] [PATCH 0/2] Add 'bcb' command to read/modify/write Android BCB
Hello U-Boot community,
The motivation behind adding the 'bcb' command is largely explained
in the second patch of this series. The other patch merely imports a
prerequisite header from AOSP.
This series (specifically the first patch) overlaps with [1], but it
is something agreed with Igor (see [2]).
Any comments would be appreciated.
Best regards,
Eugeniu.
[1] https://patchwork.ozlabs.org/cover/1044152/
("[U-Boot,v3,0/7] android: implement A/B boot process")
[2] https://patchwork.ozlabs.org/patch/1003998/#2145067
Eugeniu Rosca (2):
include: android_bl_msg.h: Initial import
cmd: Add 'bcb' command to read/modify/write BCB fields
cmd/Kconfig | 17 ++
cmd/Makefile | 1 +
cmd/bcb.c| 347 +++
include/android_bl_msg.h | 273 ++
4 files changed, 638 insertions(+)
create mode 100644 cmd/bcb.c
create mode 100644 include/android_bl_msg.h
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] include: android_bl_msg.h: Initial import
Import the bootloader_message.h (former bootloader.h) from AOSP. Repository: https://android.googlesource.com/platform/bootable/recovery Commit: 8e0821e6907d6016c19565b83319aff90ad1a034 Author: Tao Bao Date: Wed Apr 3 23:48:21 2019 + The bootloader_message.h basically defines the flash layout of a dedicated partition (usually called 'misc') and is needed in U-Boot in order to be able to implement a subset of Android Bootloader Requirements [1], specifically dealing with: - Communication between the bootloader and recovery - Handling of A/B (Seamless) System Updates [2] With respect to the in-tree vs out-of-tree file differences: - license matches https://patchwork.ozlabs.org/patch/1003998/ - filename is changed to android_bl_msg.h, as per Simon's comment [3] - the struct/macro names have been shaped by [3-4], where the two main criterias are: - Improve the syntax/readability in the global U-Boot namespace - Minimize the future integration/update efforts from the source. Particularly, the __UBOOT__ macro helps with isolating the U-Boot-unrelated parts (e.g. includes/function prototypes/etc) [1] https://source.android.com/devices/bootloader [2] https://source.android.com/devices/tech/ota/ab/ [3] https://patchwork.ozlabs.org/patch/1003998/#2046141 [4] https://patchwork.ozlabs.org/patch/1003998/#2144955 Signed-off-by: Eugeniu Rosca --- include/android_bl_msg.h | 273 +++ 1 file changed, 273 insertions(+) create mode 100644 include/android_bl_msg.h diff --git a/include/android_bl_msg.h b/include/android_bl_msg.h new file mode 100644 index ..c48a1de2762b --- /dev/null +++ b/include/android_bl_msg.h @@ -0,0 +1,273 @@ +// SPDX-License-Identifier: BSD-2-Clause +/* + * This file was taken from the AOSP Project. + * Repository: https://android.googlesource.com/platform/bootable/recovery/ + * File: bootloader_message/include/bootloader_message/bootloader_message.h + * Commit: see U-Boot commit importing/updating the file in-tree + * + * Copyright (C) 2008 The Android Open Source Project + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +#ifndef _BOOTLOADER_MESSAGE_H +#define _BOOTLOADER_MESSAGE_H + +#ifndef __UBOOT__ +#include +#include +#include +#else +#include +#include +#endif + +#ifdef __UBOOT__ +/* U-Boot-specific types for improved syntax/readability */ +typedef struct bootloader_message andr_bl_msg; +typedef struct bootloader_message_ab andr_bl_msg_ab; +typedef struct bootloader_control andr_bl_control; +#endif + +// Spaces used by misc partition are as below: +// 0 - 2K For bootloader_message +// 2K - 16KUsed by Vendor's bootloader (the 2K - 4K range may be optionally used +// as bootloader_message_ab struct) +// 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B devices +// Note that these offsets are admitted by bootloader,recovery and uncrypt, so they +// are not configurable without changing all of them. + +#ifndef __UBOOT__ +static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0; +static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024; +#else +#define ANDROID_MISC_BM_OFFSET 0 +#define ANDROID_MISC_WIPE_OFFSET SZ_16K +#endif + +/* Bootloader Message (2-KiB) + * + * This structure describes the content of a block in flash + * that is used for recovery and the bootloader to talk to + * each other. + * + * The command field is updated by linux when it wants to + * reboot into recovery or to update radio or bootloader firmware. + * It is also updated by the bootloader when firmware update + * is complete (to boot into recovery for any final cleanup) + * + * The status field was used by the bootloader after the completion + * of an "update-radio" or "update-hboot" command, which has been + * deprecated since Froyo. + * + * The recovery field is only written by linux and used + * for the system to send a message to recovery or the + * other way around. + * + * The stage field is written by packages which restart themselves + * multiple times, so that the UI can reflect which invocation of the + * package it is. If the value is of the format "#/#" (eg, "1/3"), + * the UI will add a simple indicator of that status. + * + * We used to have slot_suffix field for A/B boot control metadata in + * this struct, which gets unintentionally cleared by recovery or + * uncrypt. Move it into struct bootloader_message_ab to avoid the
Re: [U-Boot] [PATCH v4 2/4] imx: move BOARD_SIZE_CHECK to main Makefile
On 4/5/19 3:05 PM, Fabio Estevam wrote: > Hi Heinrich, > > On Tue, Apr 2, 2019 at 2:19 PM Heinrich Schuchardt wrote: >> >> We currently have duplicate definitions for BOARD_SIZE_CHECK in Makefile >> and arch/arm/mach-imx/Makefile. >> >> Move the board size check from arch/arm/mach-imx/Makefile to Makefile. >> >> Depending on the value of CONFIG_BOARD_SIZE_LIMIT an error like an error >> like the following is thrown: >> >> u-boot-dtb.imx exceeds file size limit: >> limit: 503696 bytes >> actual: 509720 bytes >> excess: 6024 bytes >> make: *** [Makefile:1051: u-boot-dtb.imx] Error 1 >> >> Signed-off-by: Heinrich Schuchardt > > Yes, it makes sense. No need for a imx specific size check: > > Reviewed-by: Fabio Estevam > Thanks for reviewing. @Stefano: I have assigned this single patch to you in patchwork to please pick-up for the imx tree. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_loader: correct CTRL-A - CTRL-Z console input
In the extended text input protocol CTRL-A - CTRL-Z have to be signaled as
Unicode characters a-z or A-Z depending on the shift state and not as 0x01
to 0x1a.
Update Python unit test.
This patch is required for using the EFI shell `edit` command.
Signed-off-by: Heinrich Schuchardt
---
v2:
Update Python unit test.
---
lib/efi_loader/efi_console.c | 17 +
test/py/tests/test_efi_selftest.py | 2 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 8e0965bfc8..051fc1d339 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -797,9 +797,26 @@ static efi_status_t EFIAPI efi_cin_read_key_stroke_ex(
ret = EFI_NOT_READY;
goto out;
}
+ /*
+* CTRL+A - CTRL+Z have to be signaled as a - z.
+* SHIFT+CTRL+A - SHIFT+CTRL+Z have to be signaled as A - Z.
+*/
+ switch (next_key.key.unicode_char) {
+ case 0x01 ... 0x07:
+ case 0x0b ... 0x0c:
+ case 0x0e ... 0x1a:
+ if (!(next_key.key_state.key_toggle_state &
+ EFI_CAPS_LOCK_ACTIVE) ^
+ !(next_key.key_state.key_shift_state &
+ (EFI_LEFT_SHIFT_PRESSED | EFI_RIGHT_SHIFT_PRESSED)))
+ next_key.key.unicode_char += 0x40;
+ else
+ next_key.key.unicode_char += 0x60;
+ }
*key_data = next_key;
key_available = false;
efi_con_in.wait_for_key->is_signaled = false;
+
out:
return EFI_EXIT(ret);
}
diff --git a/test/py/tests/test_efi_selftest.py
b/test/py/tests/test_efi_selftest.py
index 36b35ee536..bc226a8e63 100644
--- a/test/py/tests/test_efi_selftest.py
+++ b/test/py/tests/test_efi_selftest.py
@@ -141,7 +141,7 @@ def test_efi_selftest_text_input_ex(u_boot_console):
u_boot_console.run_command(cmd=chr(4), wait_for_echo=False,
send_nl=False, wait_for_prompt=False)
m = u_boot_console.p.expect(
- ['Unicode char 4 \(unknown\), scan code 0 \(CTRL\+Null\)'])
+ ['Unicode char 100 \\(\'d\'\\), scan code 0 \\(CTRL\\+Null\\)'])
if m != 0:
raise Exception('EOT failed in \'text input\' test')
u_boot_console.drain_console()
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: phy: implement fallback mechanism for negative phy adresses
Hi Tom,
> Hi Hannes,
>
> > Negative phy-addresses can occour if the caller function was not
> > able to determine a valid phy address (from device-tree for
> > example). In this case we catch this here and search for ANY phy
> > device on the given mdio- bus.
> >
> > Signed-off-by: Hannes Schmelzer
> >
> > ---
> >
> > Changes in v3:
> > - fix commit message
> >
> > Changes in v2:
> > - cosmetic changes
> >
> > drivers/net/phy/phy.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> > index 0c8b29d..4e8d294 100644
> > --- a/drivers/net/phy/phy.c
> > +++ b/drivers/net/phy/phy.c
> > @@ -922,13 +922,14 @@ struct phy_device *phy_connect(struct mii_dev
> > *bus, int addr, #endif
> > {
> > struct phy_device *phydev = NULL;
> > + uint mask = (addr > 0) ? (1 << addr) : 0x;
> >
> > #ifdef CONFIG_PHY_FIXED
> > phydev = phy_connect_fixed(bus, dev, interface);
> > #endif
> >
> > if (!phydev)
> > - phydev = phy_find_by_mask(bus, 1 << addr,
> > interface);
> > + phydev = phy_find_by_mask(bus, mask, interface);
> >
> > if (phydev)
> > phy_connect_dev(phydev, dev);
>
> Tested-by: Lukasz Majewski
>
> Test HW: imx53 (HSC device).
>
> Could this patch be applied to v2019.04, please ?
>
> (So there is NO need to revert:
> "drivers/net/fec: phy_init: remove redundant logic").
>
Tom, do you plan to add thins commit to v2019.04 ?
>
> 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
pgpX0u6m5vlgC.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pico-imx6ul: Add DWARF baseboard support
This add the boot menu option for the DWARF baseboard as well as a specific config file for users which wish to use it as a pre-defined board. Signed-off-by: Otavio Salvador --- configs/pico-dwarf-imx6ul_defconfig | 64 + include/configs/pico-imx6ul.h | 6 ++- 2 files changed, 68 insertions(+), 2 deletions(-) create mode 100644 configs/pico-dwarf-imx6ul_defconfig diff --git a/configs/pico-dwarf-imx6ul_defconfig b/configs/pico-dwarf-imx6ul_defconfig new file mode 100644 index 00..e7af415abd --- /dev/null +++ b/configs/pico-dwarf-imx6ul_defconfig @@ -0,0 +1,64 @@ +CONFIG_ARM=y +CONFIG_ARCH_MX6=y +CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_TARGET_PICO_IMX6UL=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL=y +CONFIG_SPL_LIBDISK_SUPPORT=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" +CONFIG_BOOTDELAY=3 +CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" +CONFIG_DEFAULT_FDT_FILE="imx6ul-pico-dwarf.dtb" +CONFIG_BOUNCE_BUFFER=y +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SPL_USB_HOST_SUPPORT=y +CONFIG_SPL_USB_GADGET=y +CONFIG_SPL_USB_SDP_SUPPORT=y +CONFIG_CMD_BOOTMENU=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_DFU=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_SDP=y +CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx6ul-pico-pi" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_DFU_MMC=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_SIZE=0x1000 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y +CONFIG_PHYLIB=y +CONFIG_PHY_MICREL=y +CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y +CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_PFUZE100=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_PFUZE100=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_REGULATOR_GPIO=y +CONFIG_USB=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_CI_UDC=y diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h index 050f69801b..f0dadc4b1e 100644 --- a/include/configs/pico-imx6ul.h +++ b/include/configs/pico-imx6ul.h @@ -64,9 +64,11 @@ "rootfs part 0 1\0" \ #define BOOTMENU_ENV \ - "bootmenu_0=Boot using PICO-Hobbit baseboard=" \ + "bootmenu_0=Boot using PICO-Dwarf baseboard=" \ + "setenv fdtfile imx6ul-pico-dwarf.dtb\0" \ + "bootmenu_1=Boot using PICO-Hobbit baseboard=" \ "setenv fdtfile imx6ul-pico-hobbit.dtb\0" \ - "bootmenu_1=Boot using PICO-Pi baseboard=" \ + "bootmenu_2=Boot using PICO-Pi baseboard=" \ "setenv fdtfile imx6ul-pico-pi.dtb\0" \ #define CONFIG_SYS_MMC_IMG_LOAD_PART 1 -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] common: Implement A/B metadata
Hi Eugeniu,
Sorry for the late reply.
Please go ahead,
I'm currently on a business trip, so I won't have access to my setup
with A/B till April 19 (so I definetely won't send any updates till
that time).
I'll sync with the patches you're going to send.
Thanks!
On Wed, Apr 3, 2019 at 7:55 PM Eugeniu Rosca wrote:
>
> Hi Simon, Igor, Ruslan,
>
> On Thu, Dec 6, 2018 at 4:05 AM Simon Glass wrote:
> > Hi Ruslan,
> >
> > On Tue, 27 Nov 2018 at 12:57, Ruslan Trofymenko
> > wrote:
> > >
> [..]
> > > +struct android_bootloader_message {
> >
> > How about andr_bl_msg ? Similarly below
>
> Simon, I am currently working on a new U-Boot command which requires
> the same AOSP header in-tree. Since the v4 of the whole "A/B support"
> series is still WIP by Igor (Ruslan?), may I kindly ask you whether
> you feel strong about these specific header and struct renames? We've
> recently got some feedback from Tom [1] that it should be OK to keep
> the out-of-tree headers untouched. My main motivation is 1) minimizing
> the effort of updating this specific header from upstream and 2) using
> the U-Boot-compliant header/struct names in my WIP changes. I am open
> minded if the original filename is not preserved, but the struct
> renames imply some amount of changes in the comments (see [2]). Also,
> renaming the structs will imply parsing and verifying the comments
> each time the header is updated. It's this kind of tiny bit of
> integration effort which you always want to avoid, since it doesn't
> require any creativity and can't be automated easily. I am looking
> forward for your feedback.
>
> Dear Igor, Ruslan,
>
> How should we handle the import of
> bootloader_message/include/bootloader_message/bootloader_message.h ?
> If it takes more time for you to submit the next version of A/B
> support, would it be fine for you if I do the importing of the header
> myself along with my other patches which depend on it?
>
> [1] https://patchwork.ozlabs.org/patch/1044158/#2129429
> [2] https://patchwork.ozlabs.org/patch/1044158/#2109299
>
> Many thanks,
> Eugeniu.
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
Hi Bryan, Em dom, 7 de abr de 2019 às 05:05, Bryan O'Donoghue escreveu: > > > > On 06/04/2019 22:41, Breno Matheus Lima wrote: > > Hi Bryan, > > > > Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue > > escreveu: > >> > >> > >> > >> On 05/04/2019 17:16, Breno Matheus Lima wrote: > >> Basically you've described and additional dependency the BootROM has, so > >> lets just "switch context" prior to calling into the BootROM and restore > >> to a default non-secure job-ring assignment after. > > > > Yes, this can work for OP-TEE users decrypting additional boot images > > at U-Boot level, however all users won't be able to > > authenticate/decrypt the initial boot image at BootROM level. > > I don't understand that comment, perhaps you can give an example. > You can take a look in application note AN12056: https://www.nxp.com/docs/en/application-note/AN12056.pdf Section 2.2 provides more details on the encrypted boot sequence, as you can see in Figure 1 the U-Boot image is decrypted at bootROM level after a system reset. Section 4 explains how to encrypt and sign an U-Boot image. As I mentioned in commit log, the ROM code expects DEK blobs encapsulated by the Secure World environments which commonly have JROWN_NS = 0. > > Out of > > reset CAAM job rings are assigned to TrustZone secure world and > > BootROM code is expecting blobs generated by the same environment. > > > > What about moving the job rings assignment to OP-TEE level? Something > > similar as we currently have in imx-optee-os project? > > TBH, I see that as something that should be done _anyway_ not instead > i.e. after u-boot, if you want to do 'stuff' with the CAAM you are either > > 1. Running in non-secure Linux, in which case you need the job-rings > assigned to non-secure mode or > > 2. You are running inside of a TEE, in which case you absolutely need > to have at least one job-ring > > ... and for the second case the right thing to do is to arbitrate > ownership of job-rings via a DTB > > > https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31 > > > > U-Boot is running in TrustZone secure world in most of targets, in my > > opinion it makes sense to have at least 1 job ring assigned to > > TrustZone secure world. > > But if u-boot is running in secure-world > > save_jr_context(); > setup_some_new_jr_context(); > hab_authenticate_something(); > restore_jr_context(); This can only work if we do similar operation in CMD_DEKBLOB: save_jr_context(); setup_some_new_jr_context(); blob_dek() restore_jr_context(); Both operations blob_dek() and hab_authenticate_image() at U-Boot level must have the Job Ring assigned for TrustZone secure world. The first authentication/decryption at bootROM level is expecting a DEK blobs generated by TrustZone secure world. > > As a "quick fix", that's the way I'd do it. Just pivoting on > CONFIG_OPTEE is pretty easy to break i.e. you can have CONFIG_OPTEE > defined in your u-boot config but not actually be executing a TEE, in > which case by the time you boot Linux your JR assignment is wrong.. Can you please provide more details on how this can break users that has CONFIG_OPTEE defined and are not executing a TEE? From my understanding Linux Kernel will be running in TZ secure world and JRs assigned to TZ non-secure world, CAAM driver can still be used on this condition (Similar as we currently have for mx7dsabresd target). In order to have a quick fix available, what about delaying the Job Ring assignment in U-Boot? Perhaps we can provide an U-Boot command to set the Job Ring ownership, users can add this command in their boot script just before booting Kernel and/or OP-TEE. > > The correct and flexible fix is passing a DTB descriptor that u-boot, > OPTEE and Kernel can put data into so that there's a canonical > description of which execution environment owns what. > Yes, I agree. We need a more flexible fix here. Best regards, Breno Lima ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: dts: i.MX6ULL: U-Boot specific dts for u-boot, dm-spl
u-boot,dm-spl property is specific to U-Boot, so created one
for i.MX6ULL platforms.
Signed-off-by: Parthiban Nallathambi
---
arch/arm/dts/imx6ull-u-boot.dtsi | 34
board/phytec/pcl063/MAINTAINERS | 1 +
2 files changed, 35 insertions(+)
create mode 100644 arch/arm/dts/imx6ull-u-boot.dtsi
diff --git a/arch/arm/dts/imx6ull-u-boot.dtsi b/arch/arm/dts/imx6ull-u-boot.dtsi
new file mode 100644
index 00..74ca95fa2c
--- /dev/null
+++ b/arch/arm/dts/imx6ull-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Parthiban Nallathambi
+ */
+
+/ {
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/board/phytec/pcl063/MAINTAINERS b/board/phytec/pcl063/MAINTAINERS
index 70e03cfe71..7d9978c339 100644
--- a/board/phytec/pcl063/MAINTAINERS
+++ b/board/phytec/pcl063/MAINTAINERS
@@ -3,6 +3,7 @@ M: Martyn Welch
M: Parthiban Nallathambi
S: Maintained
F: arch/arm/dts/imx6ul-phycore-segin.dts
+F: arch/arm/dts/imx6ull-u-boot.dtsi
F: arch/arm/dts/imx6ull-phycore-segin.dts
F: arch/arm/dts/pcl063-common.dtsi
F: board/phytec/pcl063/
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Is running another .scr file from within boot.scr possible?
U.Mutlu wrote on 04/07/2019 08:05 PM: Hi, is it possible to exec another .scr file from within boot.scr ? Or is there another alternative to auto-run a different script file? The goal is to have different script files, one say for normal boot from SD, and the other say for booting from a tftp-server. Btw, is the interpreter that runs the boot.scr a sh/bash interpreter? Another question is: once boot.scr is started, is it still possible conditionally or unconditionally to return to the u-boot CLI prompt? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] watchdog: Move watchdog_dev to data section (BSS may not be cleared)
Am 03.04.19 um 09:12 schrieb Stefan Roese:
> This patch moves all instances of static "watchdog_dev" declarations to
> the "data" section. This may be needed, as the BSS may not be cleared
> in the early U-Boot phase, where watchdog_reset() is already beeing
> called. This may result in incorrect pointer access, as the check to
> "!watchdog_dev" in watchdog_reset() may not be true and the function
> may continue to run.
>
> Signed-off-by: Stefan Roese
> Cc: Heiko Schocher
> Cc: Tom Rini
> Cc: Michal Simek
> Cc: "Marek Behún"
> Cc: Daniel Schwierzeck
> ---
> v2:
> - Remove now superfluous explicit clearing of watchdog_dev in Xilinx
> zynq and zynqmp board_early_init_f() as suggested by Michal
>
> arch/mips/mach-mt7620/cpu.c | 2 +-
> board/CZ.NIC/turris_mox/turris_mox.c | 2 +-
> board/CZ.NIC/turris_omnia/turris_omnia.c | 2 +-
> board/xilinx/microblaze-generic/microblaze-generic.c | 2 +-
> board/xilinx/zynq/board.c| 7 +--
> board/xilinx/zynqmp/zynqmp.c | 7 +--
> 6 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/arch/mips/mach-mt7620/cpu.c b/arch/mips/mach-mt7620/cpu.c
> index 9e0ca716f7..fe74f26a54 100644
> --- a/arch/mips/mach-mt7620/cpu.c
> +++ b/arch/mips/mach-mt7620/cpu.c
> @@ -70,7 +70,7 @@ int print_cpuinfo(void)
> }
>
> #ifdef CONFIG_WATCHDOG
> -static struct udevice *watchdog_dev;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
to simplify that line you could use __section(".data")
>
> /* Called by macro WATCHDOG_RESET */
> void watchdog_reset(void)
> diff --git a/board/CZ.NIC/turris_mox/turris_mox.c
> b/board/CZ.NIC/turris_mox/turris_mox.c
> index 65d50a92dd..96cb9c7e5c 100644
> --- a/board/CZ.NIC/turris_mox/turris_mox.c
> +++ b/board/CZ.NIC/turris_mox/turris_mox.c
> @@ -120,7 +120,7 @@ int board_fix_fdt(void *blob)
> #endif
>
> #ifdef CONFIG_WDT_ARMADA_37XX
> -static struct udevice *watchdog_dev;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
>
> void watchdog_reset(void)
> {
> diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
> b/board/CZ.NIC/turris_omnia/turris_omnia.c
> index 1f7650cb36..c7f6479a0c 100644
> --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> @@ -365,7 +365,7 @@ static bool disable_mcu_watchdog(void)
> #endif
>
> #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT_ORION)
> -static struct udevice *watchdog_dev = NULL;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
> #endif
>
> int board_init(void)
> diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c
> b/board/xilinx/microblaze-generic/microblaze-generic.c
> index c946ec3208..28c9efa3a2 100644
> --- a/board/xilinx/microblaze-generic/microblaze-generic.c
> +++ b/board/xilinx/microblaze-generic/microblaze-generic.c
> @@ -25,7 +25,7 @@
> DECLARE_GLOBAL_DATA_PTR;
>
> #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
> -static struct udevice *watchdog_dev;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
> #endif /* !CONFIG_SPL_BUILD && CONFIG_WDT */
>
> ulong ram_base;
> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> index b4b84df576..ea26aad16f 100644
> --- a/board/xilinx/zynq/board.c
> +++ b/board/xilinx/zynq/board.c
> @@ -19,17 +19,12 @@
> DECLARE_GLOBAL_DATA_PTR;
>
> #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
> -static struct udevice *watchdog_dev;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
> #endif
>
> #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_BOARD_EARLY_INIT_F)
> int board_early_init_f(void)
> {
> -# if defined(CONFIG_WDT)
> - /* bss is not cleared at time when watchdog_reset() is called */
> - watchdog_dev = NULL;
> -# endif
> -
> return 0;
> }
> #endif
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index 5e1d2116bc..db27247850 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -25,7 +25,7 @@
> DECLARE_GLOBAL_DATA_PTR;
>
> #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
> -static struct udevice *watchdog_dev;
> +static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
> #endif
>
> #if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_ZYNQMPPL) && \
> @@ -322,11 +322,6 @@ int board_early_init_f(void)
> ret = psu_init();
> #endif
>
> -#if defined(CONFIG_WDT) && !defined(CONFIG_SPL_BUILD)
> - /* bss is not cleared at time when watchdog_reset() is called */
> - watchdog_dev = NULL;
> -#endif
> -
> return ret;
> }
>
>
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Add network support for Jaguar2 SoCs
Am 03.04.19 um 19:54 schrieb Horatiu Vultur: > v4-changes: > - address Daniel comments. > > v3-changes: > - move serdes setup in network driver and read serdes >configuration from DT. > > v2-changes: > - create serdes6g_setup and serdes1g_setup functions to be >easier to extand for future boards. > > Horatiu Vultur (4): > net: Add MSCC Jaguar2 network driver. > board: mscc: jr2: Update MSCC Jaguar2 boards > net: mscc: jaguar2: Add ethenet nodes for Jaguar2. > configs: mscc_jr2: Add network support > > arch/mips/dts/jr2_pcb110.dts | 76 +++ > arch/mips/dts/jr2_pcb111.dts | 400 > arch/mips/dts/mscc,jr2.dtsi | 116 > arch/mips/dts/serval2_pcb112.dts | 44 ++ > board/mscc/jr2/jr2.c | 23 + > configs/mscc_jr2_defconfig|6 +- > drivers/net/mscc_eswitch/Kconfig |7 + > drivers/net/mscc_eswitch/Makefile |1 + > drivers/net/mscc_eswitch/jr2_switch.c | 1075 > + > include/configs/vcoreiii.h|2 +- > include/dt-bindings/mscc/jr2_data.h | 19 + > 11 files changed, 1767 insertions(+), 2 deletions(-) > create mode 100644 drivers/net/mscc_eswitch/jr2_switch.c > create mode 100644 include/dt-bindings/mscc/jr2_data.h > series applied to u-boot-mips/next, thanks. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: add eraseenv command
Am 07.04.2019 um 19:32 schrieb Frank Wunderlich: started to include erase in the global scope...hope i'm right. https://github.com/frank-w/u-boot/commits/eraseenv_new Yes, that looks like the correct approach. where is the env-command (i need to add erase too) defined? i found no cmd/env*.[ch]... It's in cmd/nvedit.c, see function 'do_env'. Regards, Simon regards Frank Gesendet: Sonntag, 07. April 2019 um 17:58 Uhr Von: "Stefano Babic" IMHO the U_BOOT_ENV_LOCATION should be extended to add a new function pointer, and the generic command calls it. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Is running another .scr file from within boot.scr possible?
Hi, is it possible to exec another .scr file from within boot.scr ? Or is there another alternative to auto-run a different script file? The goal is to have different script files, one say for normal boot from SD, and the other say for booting from a tftp-server. Btw, is the interpreter that runs the boot.scr a sh/bash interpreter? Thx -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] phy: Add USB PHY driver for the MT76x8 (7628/7688) SoC
Am 05.04.19 um 13:44 schrieb Stefan Roese: > This driver is derived from this Linux driver: > linux/drivers/phy/ralink/phy-ralink-usb.c > > The driver sets up power and host mode, but also needs to configure PHY > registers for the MT7628 and MT7688. > > I removed the reset controller handling for the USB host and device, as > it does not seem to be necessary right now. The soft reset bits for both > devices are enabled by default and testing has shown (with hackish > reset handling added), that USB related commands work identical with > or without the reset handling. > > Please note that the resulting USB support is tested only very minimal. > I was able to detect one of my 3 currently available USB sticks. > Perhaps some further work is needed to fully support the EHCI controller > integrated in the MT76x8 SoC. > > Signed-off-by: Stefan Roese > Cc: Marek Vasut > Cc: Daniel Schwierzeck > --- > drivers/phy/Kconfig | 8 ++ > drivers/phy/Makefile | 1 + > drivers/phy/mt76x8-usb-phy.c | 161 +++ > 3 files changed, 170 insertions(+) > create mode 100644 drivers/phy/mt76x8-usb-phy.c > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: Extend PCL063 support for phyCORE-i.MX6ULL SOM
Extend PHYTEC phyBOARD-i.MX6UL for phyCORE-i.MX6UL SoM (PCL063)
with eMMC on SoM.
CPU: Freescale i.MX6ULL rev1.0 792 MHz (running at 396 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 38C
Reset cause: POR
Model: Phytec phyBOARD-i.MX6ULL-Segin SBC
Board: PHYTEC phyCORE-i.MX6ULL
DRAM: 256 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In:serial@0202
Out: serial@0202
Err: serial@0202
Net: FEC0
Working:
- Eth0
- i2C
- MMC/SD
- eMMC
- UART (1 & 5)
- USB (host & otg)
Signed-off-by: Parthiban Nallathambi
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx6ul-phycore-segin.dts | 3 +-
arch/arm/dts/imx6ull-phycore-segin.dts| 81
...{imx6ul-pcl063.dtsi => pcl063-common.dtsi} | 31 -
arch/arm/mach-imx/mx6/Kconfig | 12 ++
board/phytec/pcl063/Kconfig | 13 ++
board/phytec/pcl063/MAINTAINERS | 6 +-
board/phytec/pcl063/pcl063.c | 5 +-
board/phytec/pcl063/spl.c | 76 +++-
configs/phycore_pcl063_ull_defconfig | 54
include/configs/pcl063_ull.h | 117 ++
11 files changed, 388 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/dts/imx6ull-phycore-segin.dts
rename arch/arm/dts/{imx6ul-pcl063.dtsi => pcl063-common.dtsi} (84%)
create mode 100644 configs/phycore_pcl063_ull_defconfig
create mode 100644 include/configs/pcl063_ull.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0e2ffdb87f..431afb915f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -539,6 +539,7 @@ dtb-$(CONFIG_MX6UL) += \
dtb-$(CONFIG_MX6ULL) += \
imx6ull-14x14-evk.dtb \
imx6ull-colibri.dtb \
+ imx6ull-phycore-segin.dtb
dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb \
diff --git a/arch/arm/dts/imx6ul-phycore-segin.dts
b/arch/arm/dts/imx6ul-phycore-segin.dts
index a46012e2b4..9e6984e137 100644
--- a/arch/arm/dts/imx6ul-phycore-segin.dts
+++ b/arch/arm/dts/imx6ul-phycore-segin.dts
@@ -16,7 +16,8 @@
/dts-v1/;
-#include "imx6ul-pcl063.dtsi"
+#include "imx6ul.dtsi"
+#include "pcl063-common.dtsi"
/ {
model = "Phytec phyBOARD-i.MX6UL-Segin SBC";
diff --git a/arch/arm/dts/imx6ull-phycore-segin.dts
b/arch/arm/dts/imx6ull-phycore-segin.dts
new file mode 100644
index 00..c20a867c90
--- /dev/null
+++ b/arch/arm/dts/imx6ull-phycore-segin.dts
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Parthiban Nallathambi
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6ull.dtsi"
+#include "pcl063-common.dtsi"
+
+/ {
+ model = "Phytec phyBOARD-i.MX6ULL-Segin SBC";
+ compatible = "phytec,phyboard-imx6ull-segin", "phytec,imx6ull-pcl063",
+"fsl,imx6ull";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ i2c_rtc: rtc@68 {
+ compatible = "microcrystal,rv4162";
+ reg = <0x68>;
+ status = "okay";
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart5>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb_otg1_id>;
+ dr_mode = "otg";
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ status = "okay";
+};
+
+ {
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_TX_DATA__UART5_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x1b0b1
+ MX6UL_PAD_GPIO1_IO08__UART5_DCE_RTS 0x1b0b1
+ MX6UL_PAD_GPIO1_IO09__UART5_DCE_CTS 0x1b0b1
+ >;
+ };
+
+ pinctrl_usb_otg1_id: usbotg1idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID0x17059
+ >;
+ };
+
+};
diff --git a/arch/arm/dts/imx6ul-pcl063.dtsi b/arch/arm/dts/pcl063-common.dtsi
similarity index 84%
rename from arch/arm/dts/imx6ul-pcl063.dtsi
rename to arch/arm/dts/pcl063-common.dtsi
index 24a6a47983..f505f62230 100644
--- a/arch/arm/dts/imx6ul-pcl063.dtsi
+++ b/arch/arm/dts/pcl063-common.dtsi
@@ -7,10 +7,6 @@
* Author: Christian Hemp
*/
-/dts-v1/;
-
-#include "imx6ul.dtsi"
-
/ {
model = "Phytec phyCORE-i.MX6 Ultra Lite SOM";
compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
@@ -99,6 +95,18 @@
status = "okay";
};
+ {
+ u-boot,dm-spl;
+
Re: [U-Boot] [PATCH] mmc: add eraseenv command
started to include erase in the global scope...hope i'm right. https://github.com/frank-w/u-boot/commits/eraseenv_new where is the env-command (i need to add erase too) defined? i found no cmd/env*.[ch]... regards Frank > Gesendet: Sonntag, 07. April 2019 um 17:58 Uhr > Von: "Stefano Babic" > IMHO the U_BOOT_ENV_LOCATION should be extended to add a new function > pointer, and the generic command calls it. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting from network
Chris Packham wrote on 04/07/2019 01:22 AM:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, wrote:
I'm booting over the network (GbE) from a tftp server.
It works, but is IMHO very slow.
Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
Because TFTP sends a block at a time waiting for an ack between blocks it's
not going to be as fast as something that runs over TCP and benefits from
buffering.
One tunable you might get some use out of is $tftpblocksize, this will
increase the number of bytes per block. Try setting this to around 1400
keeping the overall Ethernet frame under 1518.
After attaching a monitor to the device, I now can see that
the cause is that sometimes the tftboot (or tftp) command fails,
but the script continues... Ie. there is missing some evaluation/test
of the return code of the command.
One better should do it in a loop with n retries. I've yet to read
in u-boot documentation on how one can do such tests in the script.
boot.cmd:
dhcp 0x4900
tftpboot 0x4600 192.168.1.201:uImage
tftpboot 0x4900 192.168.1.201:u-boot.dtb
setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
rootfstype=ext4 rw ${extra}
bootm 0x4600 - 0x4900
Btw, in the above script, can I safely replace the addresses
with ${kloadaddr} and ${fdtaddr} ?
I wonder where these variables get set or obtained from.
(I saw these variables somewhere on the net, but there was no
initialisation,
so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize.
The latter two are set after a successful load. However plenty of boards
have $fdtaddr etc in their default environment so you might have acces to
those depending on your board.
I now see that the u-boot commands "bdinfo" and "printenv" do print such infos.
I haven't grasped yet if that info is persistent, or initialized each time
by u-boot, but it seems there could be some persistent store beyond uSD
on the device.
My device is Banana Pi R1 (aka BPi-R1 or Lamobo R1). I'm relatively new
to this board, and also generally to these Raspi-like small devices.
It's IMO a nice PC-like dual-core ARMv7-A20 1GHz 32bit board with GbE router &
switch capabilities,
but I have one major problem with this board: the SSD (SATA2 3Gbps AHCI)
write-speed is only about 52 MB/s (read-speed is about 200 MB/s).
I try to find out which component is responsible for the slow write-speed:
is it the SATA driver (ahci-sunxi[1c18000.sata]), or other components (HW or
SW)?
How could one best encircle/pinpoint this SATA specific problem-source?
root@r1-3:/tmp# dmesg | grep -i "sata\|ahci"
[5.485336] ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.11
[5.592431] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off
CAP_PMP
[5.599953] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled
[5.607139] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps
0x1 impl platform mode
[5.616118] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only
pio slum part ccc
[5.625664] scsi host0: ahci-sunxi
[5.629551] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port
0x100 irq 37
[5.963890] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
root@r1-3:/tmp# cat /proc/interrupts
CPU0 CPU1
...
37: 3330 2813 GICv2 88 Level ahci-sunxi[1c18000.sata]
...
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment.
Is there another method to get the u-boot output (or log) to be sent to a
remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its
only good for output.
I'd still recommend getting a serial cable if your going to be playing with
u-boot becasue at some point you'll do something that stops your board from
booting.
Yes, I've already ordered such an adapter cable, will get it tomorrow or
tuesday.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] common: Implement A/B metadata
Hi Simon, Igor, All,
On Wed, Apr 03, 2019 at 07:55:30PM +0200, Eugeniu Rosca wrote:
> Hi Simon, Igor, Ruslan,
>
> On Thu, Dec 6, 2018 at 4:05 AM Simon Glass wrote:
> > Hi Ruslan,
> >
> > On Tue, 27 Nov 2018 at 12:57, Ruslan Trofymenko
> > wrote:
> > >
> [..]
> > > +struct android_bootloader_message {
> >
> > How about andr_bl_msg ? Similarly below
>
> Simon, I am currently working on a new U-Boot command which requires
> the same AOSP header in-tree. Since the v4 of the whole "A/B support"
> series is still WIP by Igor (Ruslan?), may I kindly ask you whether
> you feel strong about these specific header and struct renames? We've
> recently got some feedback from Tom [1] that it should be OK to keep
> the out-of-tree headers untouched. My main motivation is 1) minimizing
> the effort of updating this specific header from upstream and 2) using
> the U-Boot-compliant header/struct names in my WIP changes. I am open
> minded if the original filename is not preserved, but the struct
> renames imply some amount of changes in the comments (see [2]). Also,
> renaming the structs will imply parsing and verifying the comments
> each time the header is updated. It's this kind of tiny bit of
> integration effort which you always want to avoid, since it doesn't
> require any creativity and can't be automated easily. I am looking
> forward for your feedback.
>
> Dear Igor, Ruslan,
>
> How should we handle the import of
> bootloader_message/include/bootloader_message/bootloader_message.h ?
> If it takes more time for you to submit the next version of A/B
> support, would it be fine for you if I do the importing of the header
> myself along with my other patches which depend on it?
>
> [1] https://patchwork.ozlabs.org/patch/1044158/#2129429
> [2] https://patchwork.ozlabs.org/patch/1044158/#2109299
Apologize for making another iteration on this, but what about below
solution WRT struct renames upon importing bootloader_message.h in-tree.
The following typedef statements (placed in the imported header) would
allow keeping the original structures and the associated comments
untouched (hence speeding up the updates from the source), while U-Boot
would use use the new/rightmost types mirroring the upstream ones.
typedef struct bootloader_message andr_bl_msg;
typedef struct bootloader_message_abandr_bl_msg_ab;
typedef struct bootloader_control andr_bl_control;
>
> Many thanks,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] why is there no ".u-boot.map.cmd" generated?
short followup to earlier question ... i was going to check the file .u-boot.map.cmd to see which command was used to generate it but, unlike numerous other files of that form, that file has no associated .cmd file. any reason for that? rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] using objdump/readelf/nm to dump symbols by individual source file?
i'm doing this in the context of building for ARM with a linaro
toolchain, but i'm sure it's equally valid in the context of a native
build.
i'm trying to generate the same output as u-boot.map, but more
condensed and with each symbol associated with its original source
file (if that's even possible).
for example, there are a couple weak symbols in board_f.c:
__weak int arch_cpu_init(void)
{
return 0;
}
__weak int mach_cpu_init(void)
{
return 0;
}
so depending on the target board, the final included version of such a
routine might come from board_f.c, or it might be overridden at the
board level.
you can sort of see this in u-boot.map:
.text.arch_cpu_init
0x0x8 common/built-in.o
...
.text.mach_cpu_init
0x04011cac0x8 common/built-in.o
0x04011cacmach_cpu_init
except i was hoping to be able to list included symbols by their
*original* source file, and listed one file at a time, so the output
would have the format:
board_f.o
mach_cpu_init
... other stuff from board_f.o
i could swear i once knew how to do this, but i've forgotten (or
perhaps i'm misremembering). is there some variation of objdump,
readelf or nm that will do what i want? i need nothing other than, for
each source file, the symbols that were included in the final ELF file
from that source file.
can i do this?
rday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: add eraseenv command
Hi Frank, On 07/04/19 17:20, Frank Wunderlich wrote: > Hi Stefano, > > I agree a global env erase which calls device-specific function is better > than current implementation. I havn't figured out how i can implement it. Is > there a simple example for this? > IMHO the U_BOOT_ENV_LOCATION should be extended to add a new function pointer, and the generic command calls it. Regards, Stefano > Regards Frank > > Am 7. April 2019 14:55:42 MESZ schrieb Stefano Babic : >> Hi Frank, >> >> On 06/04/19 20:12, Frank Wunderlich wrote: >>> "mmc eraseenv" allows to erase the section on mmc where env is stored >>> >> >> Why do we need a specific command for MMC ? If we need such a command, >> should it not unaware of the storage ? That is a "env eraseenv", and >> this calls the corresponding function for SPI /MMC / NAND /.. ? -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] test: env: Enable env unit tests by default
If CONFIG_UNIT_TEST is enabled we should enable the individual tests by default to ensure good test coverage. Signed-off-by: Heinrich Schuchardt --- Tests ok on Travis CI: https://travis-ci.org/xypron2/u-boot/builds/516825681 --- test/env/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/test/env/Kconfig b/test/env/Kconfig index ff164132e9..6cb82337b3 100644 --- a/test/env/Kconfig +++ b/test/env/Kconfig @@ -1,6 +1,7 @@ config UT_ENV bool "Enable env unit tests" depends on UNIT_TEST + default y help This enables the 'ut env' command which runs a series of unit tests on the env code. -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: add eraseenv command
Hi Stefano, I agree a global env erase which calls device-specific function is better than current implementation. I havn't figured out how i can implement it. Is there a simple example for this? Regards Frank Am 7. April 2019 14:55:42 MESZ schrieb Stefano Babic : >Hi Frank, > >On 06/04/19 20:12, Frank Wunderlich wrote: >> "mmc eraseenv" allows to erase the section on mmc where env is stored >> > >Why do we need a specific command for MMC ? If we need such a command, >should it not unaware of the storage ? That is a "env eraseenv", and >this calls the corresponding function for SPI /MMC / NAND /.. ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] has anyone documented the entire "make ..._defconfig" process?
for the sake of an upcoming embedded linux class, i want to demonstrate how various files in the current u-boot contribute to, and are processed by, the initial configuration step to finally produce the resulting .config file. first, a possibly dumb question -- is the .config file the sole generated artifact of the configuration process? it would appear to be based on using git to see what else was created, and .config seems to be it. is that true? and getting into the meat of the question, as an example, i decided to document how u-boot processes numerous files to produce that .config file for the zynq zedboard, and i've already written some of that here: https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_configuration the point is to show how, from the simple command: $ make zynq_zed_defconfig u-boot consults various Makefile, Kconfig, config.mk files, board files and so on to come up with the final .config. if someone already did that once upon a time, that'd be great, but i'm going to guess i'm on my own here. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: add eraseenv command
Hi Frank,
On 06/04/19 20:12, Frank Wunderlich wrote:
> "mmc eraseenv" allows to erase the section on mmc where env is stored
>
Why do we need a specific command for MMC ? If we need such a command,
should it not unaware of the storage ? That is a "env eraseenv", and
this calls the corresponding function for SPI /MMC / NAND /.. ?
Best regards,
Stefano Babic
> Signed-off-by: Frank Wunderlich
> ---
> cmd/mmc.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 8bc3648193..b8e2c353b4 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -441,6 +441,37 @@ static int do_mmc_erase(cmd_tbl_t *cmdtp, int flag,
>
> return (n == cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
> }
> +
> +static int do_mmc_erase_env(cmd_tbl_t *cmdtp, int flag,
> + int argc, char * const argv[])
> +{
> + struct mmc *mmc;
> + u32 blk, cnt, n;
> +
> + if (argc != 1)
> + return CMD_RET_USAGE;
> +
> + mmc = init_mmc_device(curr_device, false);
> +
> + if (!mmc)
> + return CMD_RET_FAILURE;
> +
> + blk = CONFIG_ENV_OFFSET / mmc->read_bl_len;
> + cnt = CONFIG_ENV_SIZE / mmc->read_bl_len;
> +
> + printf("\nMMC erase env: dev # %d, block # %d (0x%8x), count %d
> (0x%8x)",
> +curr_device, blk, blk * mmc->read_bl_len,
> +cnt, cnt * mmc->read_bl_len);
> +
> + if (mmc_getwp(mmc) == 1) {
> + printf("Error: card is write protected!\n");
> + return CMD_RET_FAILURE;
> + }
> + n = blk_derase(mmc_get_blk_desc(mmc), blk, cnt);
> + printf("%d blocks erased: %s\n", n, (n == cnt) ? "OK" : "ERROR");
> +
> + return (n == cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
> +}
> #endif
>
> static int do_mmc_rescan(cmd_tbl_t *cmdtp, int flag,
> @@ -878,6 +909,7 @@ static cmd_tbl_t cmd_mmc[] = {
> #if CONFIG_IS_ENABLED(MMC_WRITE)
> U_BOOT_CMD_MKENT(write, 4, 0, do_mmc_write, "", ""),
> U_BOOT_CMD_MKENT(erase, 3, 0, do_mmc_erase, "", ""),
> + U_BOOT_CMD_MKENT(eraseenv, 1, 0, do_mmc_erase_env, "", ""),
> #endif
> #if CONFIG_IS_ENABLED(CMD_MMC_SWRITE)
> U_BOOT_CMD_MKENT(swrite, 3, 0, do_mmc_sparse_write, "", ""),
> @@ -940,6 +972,7 @@ U_BOOT_CMD(
> "mmc swrite addr blk#\n"
> #endif
> "mmc erase blk# cnt\n"
> + "mmc eraseenv - erase environment\n"
> "mmc rescan\n"
> "mmc part - lists available partition on current mmc device\n"
> "mmc dev [dev] [part] - show or set current mmc device [partition]\n"
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 7/9] armv8: lx2160a: enable PCIe support
> -Original Message- > From: Z.q. Hou > Sent: Monday, March 25, 2019 7:55 AM > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain > ; York Sun ; > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar > Kushwaha ; Mingkai Hu > ; M.h. Lian ; > bmeng...@gmail.com > Cc: Z.q. Hou > Subject: [RESEND PATCHv4 7/9] armv8: lx2160a: enable PCIe support > > From: Hou Zhiqiang > > Enable the PCIe Gen4 controller driver and e1000 for LX2160ARDB and > LX2160AQDS boards. > > Signed-off-by: Hou Zhiqiang > --- > V4: > - Add PCI command support > - Enable PCIe in more LX2160A defconfigs > > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 5 + > configs/lx2160aqds_tfa_defconfig | 6 ++ > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 5 + > configs/lx2160ardb_tfa_defconfig | 6 ++ > 4 files changed, 22 insertions(+) > Generate defconfig using make savedefconfig --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 5/9] pci: ls_pcie_g4: add device tree fixups for PCI Stream IDs
> -Original Message-
> From: Z.q. Hou
> Sent: Monday, March 25, 2019 7:55 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain
> ; York Sun ;
> sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar
> Kushwaha ; Mingkai Hu
> ; M.h. Lian ;
> bmeng...@gmail.com
> Cc: Z.q. Hou
> Subject: [RESEND PATCHv4 5/9] pci: ls_pcie_g4: add device tree fixups for PCI
> Stream IDs
>
> From: Hou Zhiqiang
>
> Add the infrastructure for Layerscape SoCs PCIe Gen4 controller to update
> device tree nodes to convey SMMU stream IDs in the device tree.
>
> Signed-off-by: Hou Zhiqiang
> ---
> V4:
> - No change
>
> drivers/pci/Makefile | 3 +-
> drivers/pci/pcie_layerscape_gen4.c | 5 -
> drivers/pci/pcie_layerscape_gen4_fixup.c | 249 +++
> 3 files changed, 251 insertions(+), 6 deletions(-) create mode 100644
> drivers/pci/pcie_layerscape_gen4_fixup.c
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
> 7f585aad55..8ee828af6d 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
> obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
> obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
> obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
> -obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o
> +obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o \
> + pcie_layerscape_gen4_fixup.o
> obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
> obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o diff --git
> a/drivers/pci/pcie_layerscape_gen4.c b/drivers/pci/pcie_layerscape_gen4.c
> index fbe7d35911..4e0d5b168e 100644
> --- a/drivers/pci/pcie_layerscape_gen4.c
> +++ b/drivers/pci/pcie_layerscape_gen4.c
> @@ -570,8 +570,3 @@ U_BOOT_DRIVER(pcie_layerscape_gen4) = {
> .probe = ls_pcie_g4_probe,
> .priv_auto_alloc_size = sizeof(struct ls_pcie_g4), };
> -
> -/* No any fixup so far */
> -void ft_pci_setup(void *blob, bd_t *bd) -{ -} diff --git
> a/drivers/pci/pcie_layerscape_gen4_fixup.c
> b/drivers/pci/pcie_layerscape_gen4_fixup.c
> new file mode 100644
> index 00..ceeea17f19
> --- /dev/null
> +++ b/drivers/pci/pcie_layerscape_gen4_fixup.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2018 NXP
Copyright should be now 2018-2019
Check for other files also.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCHv4 2/9] armv8: lx2160a: add MMU table entries for PCIe
> -Original Message-
> From: Z.q. Hou
> Sent: Monday, March 25, 2019 7:54 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain
> ; York Sun ;
> sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar
> Kushwaha ; Mingkai Hu
> ; M.h. Lian ;
> bmeng...@gmail.com
> Cc: Z.q. Hou
> Subject: [RESEND PATCHv4 2/9] armv8: lx2160a: add MMU table entries for PCIe
>
> From: Hou Zhiqiang
>
> The lx2160a have up to 6 PCIe controllers and have different address and size
> of
> PCIe region.
>
> Signed-off-by: Hou Zhiqiang
> ---
> V4:
> - No change
>
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 12
> arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 2 ++
> .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 14 +-
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index 978d46b32f..2805e5f6f2 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -257,6 +257,18 @@ static struct mm_region final_map[] = {
> PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN
> },
> +#endif
> +#ifdef CONFIG_ARCH_LX2160A
Request to avoid SoC name in #ifdef. Use #ifdef SYS_PCIE5_PHYS_ADDR,
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] armv8: ls1028aqds: Add support of LS1028AQDS
> -Original Message- > From: Yuantian Tang > Sent: Wednesday, April 3, 2019 12:48 PM > To: Prabhakar Kushwaha > Cc: albert.u.b...@aribaud.net; Sudhanshu Gupta > ; Harninder Rai ; Rajesh > Bhagat ; Bhaskar Upadhaya > ; u-boot@lists.denx.de; Andy Tang > > Subject: [PATCH 3/3 v2] armv8: ls1028aqds: Add support of LS1028AQDS > > From: Tang Yuantian > > LS1028AQDS Development System is a high-performance computing, evaluation, > and development platform that supports LS1028A QorIQ Architecture processor. > > Signed-off-by: Sudhanshu Gupta > Signed-off-by: Rai Harninder > Signed-off-by: Rajesh Bhagat > Signed-off-by: Bhaskar Upadhaya > Signed-off-by: Tang yuantian > --- General comment - avoid FSPI, XSPI related word, configs as no flexspi driver in upstream - avoid enetc related word as no enetc driver in upstream - Avoid #else part of CONFIG_TFABOOT as TFA boot is only supported mechanism, - Remove DDR related code as TFA doing DDR init - generate defconfig using make savedefcofig Nut shell: Take care of all review comments from RDB patch --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] armv8: ls1028ardb: Add support for LS1028ARDB platform
> -Original Message-
> From: Yuantian Tang
> Sent: Wednesday, April 3, 2019 12:48 PM
> To: Prabhakar Kushwaha
> Cc: albert.u.b...@aribaud.net; Sudhanshu Gupta
> ; Harninder Rai ; Rajesh
> Bhagat ; Bhaskar Upadhaya
> ; u-boot@lists.denx.de; Andy Tang
>
> Subject: [PATCH 2/3 v2] armv8: ls1028ardb: Add support for LS1028ARDB
> platform
>
> From: Tang Yuantian
>
> LS1028A is an ARMv8 implementation. LS1028ARDB is an evaluatoin platform
> that supports the LS1028A family SoCs. This patch add basic support of the
> platform.
>
> Signed-off-by: Sudhanshu Gupta
> Signed-off-by: Rai Harninder
> Signed-off-by: Rajesh Bhagat
> Signed-off-by: Bhaskar Upadhaya
> Signed-off-by: Tang Yuantian
> ---
> v2:
> - fix many issues
> arch/arm/Kconfig| 12 ++
> arch/arm/cpu/armv8/Kconfig | 1 +
> arch/arm/dts/fsl-ls1028a-rdb.dts| 92
> arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
> board/freescale/ls1028a/Kconfig | 38 +
> board/freescale/ls1028a/MAINTAINERS | 10 ++
> board/freescale/ls1028a/Makefile| 8 +
> board/freescale/ls1028a/README | 79 ++
> board/freescale/ls1028a/ddr.c | 284
>
> board/freescale/ls1028a/ddr.h | 46 ++
> board/freescale/ls1028a/ls1028a.c | 194
> configs/ls1028ardb_tfa_defconfig| 61
> include/configs/ls1028a_common.h| 243
> ++
> include/configs/ls1028ardb.h| 82 +++
> 14 files changed, 1151 insertions(+), 1 deletion(-) create mode 100644
> arch/arm/dts/fsl-ls1028a-rdb.dts create mode 100644
> board/freescale/ls1028a/Kconfig create mode 100644
> board/freescale/ls1028a/MAINTAINERS
> create mode 100644 board/freescale/ls1028a/Makefile create mode 100644
> board/freescale/ls1028a/README create mode 100644
> board/freescale/ls1028a/ddr.c create mode 100644
> board/freescale/ls1028a/ddr.h create mode 100644
> board/freescale/ls1028a/ls1028a.c create mode 100644
> configs/ls1028ardb_tfa_defconfig create mode 100644
> include/configs/ls1028a_common.h create mode 100644
> include/configs/ls1028ardb.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f42ecce..aaaf36a
> 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1203,6 +1203,17 @@ config TARGET_LS1012AFRDM
> development platform that supports the QorIQ LS1012A
> Layerscape Architecture processor.
>
> +config TARGET_LS1028ARDB
> + bool "Support ls1028ardb"
> + select ARCH_LS1028A
> + select ARM64
> + select ARMV8_MULTIENTRY
> + help
> + Support for Freescale LS1028ARDB platform
> + The LS1028A Development System (RDB) is a high-performance
> + development platform that supports the QorIQ LS1028A
> + Layerscape Architecture processor.
> +
> config TARGET_LS1088ARDB
> bool "Support ls1088ardb"
> select ARCH_LS1088A
> @@ -1585,6 +1596,7 @@ source "board/freescale/ls2080a/Kconfig"
> source "board/freescale/ls2080aqds/Kconfig"
> source "board/freescale/ls2080ardb/Kconfig"
> source "board/freescale/ls1088a/Kconfig"
> +source "board/freescale/ls1028a/Kconfig"
> source "board/freescale/ls1021aqds/Kconfig"
> source "board/freescale/ls1043aqds/Kconfig"
> source "board/freescale/ls1021atwr/Kconfig"
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index
> f053603..a4fa63b 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -104,6 +104,7 @@ config PSCI_RESET
> !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
> !TARGET_LS1012A2G5RDB && !TARGET_LS1012AQDS && \
> !TARGET_LS1012AFRWY && \
> +!TARGET_LS1028ARDB && \
> !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
> !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
> !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ diff --
> git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
> new file mode 100644
> index 000..e86ba06
> --- /dev/null
> +++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * NXP ls1028ARDB device tree source
> + *
> + * Copyright 2019 NXP
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls1028a.dtsi"
> +
> +/ {
> + model = "NXP Layerscape 1028a RDB Board";
> + compatible = "fsl,ls1028a-rdb", "fsl,ls1028a"; };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
When flexspi driver is not in upstream. Then why fspi status is getting changed
to "ok"
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status =
Re: [U-Boot] [PATCH 1/3 v2] armv8: ls1028a: Add NXP LS1028A SoC support
> -Original Message- > From: Yuantian Tang > Sent: Wednesday, April 3, 2019 12:48 PM > To: Prabhakar Kushwaha > Cc: albert.u.b...@aribaud.net; Sudhanshu Gupta > ; Harninder Rai ; Rajesh > Bhagat ; Bhaskar Upadhaya > ; u-boot@lists.denx.de; Andy Tang > > Subject: [PATCH 1/3 v2] armv8: ls1028a: Add NXP LS1028A SoC support > > LS1028A processor integrates two 64-bit Arm Cortex-A72 cores with a GPU and > LCD controller, as well as TSN-enabled Ethernet ports and a TSN-enabled switch > with four external ports. > The high performance Cortex-A72 cores, performing above 16,000 CoreMarks, > combined with 2.5 Gbit Ethernet, PCI express Gen 3.0, SATA 3.0, USB 3.0 and > Octal/Quad SPI interfaces provide capabilities for a number of industrial and > embedded applications. The device provides excellent integration with the new > Time-Sensitive Networking standards and enables a number of TSN applications > > Features Summary > * Two 32/64-bit Arm v8 Cortex-A72 CPUs > * Cache coherent interconnect fabric (CCI-400) > * 32-bit DDR3L/DDR4 SDRAM memory controller with ECC support > * LCD controller and DisplayPort/eDP interface > * Graphics processing unit > * TSN-capable Ethernet Switch with four external ports > * Ethernet Controller (ENETC) with TSN functionality > * Four SerDes lanes with two PLLs for high-speed peripheral interfaces > * Additional peripheral interfaces > * Two high-speed USB 3.0 controllers > * Two eSDHC controllers > * Two controller area network (FlexCAN) modules > * supporting flexible datarate (FD) > * Three serial peripheral interface (SPI) controllers > * Flexible SPI interface (FlexSPI) controller > * Eight I2C controllers > * Six LPUARTs > * 16550-compliant DUART > * General Purpose IO (GPIO) > * Eight FlexTimers/PWM controllers > * Six asynchronous audio interface (SAI) > * Support for hardware virtualization and partitioning enforcement > * QorIQ platform's trust architecture 3.0 > * Queue direct memory access controller (qDMA) > * Enhanced direct memory access controller (eDMA) > * Global programmable interrupt controller (GIC) > * Arm generic timer > * Thermal Monitor Unit (TMU) > It looks to be marketing description This patch is not supporting all above features. So update description with whatever supported by this patch. > Signed-off-by: Sudhanshu Gupta > Signed-off-by: Rai Harninder > Signed-off-by: Rajesh Bhagat > Signed-off-by: Bhaskar Upadhaya > Signed-off-by: Tang Yuantian > --- > v2: > - fix many issues > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 39 ++- > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 4 + > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 3 + > arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc | 51 > arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 88 +++ > arch/arm/dts/fsl-ls1028a.dtsi | 280 > + > arch/arm/include/asm/arch-fsl-layerscape/config.h | 61 + > .../include/asm/arch-fsl-layerscape/fsl_serdes.h | 16 ++ > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 9 + > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 + > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 2 +- > 11 files changed, 552 insertions(+), 2 deletions(-) create mode 100644 > arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c > create mode 100644 arch/arm/dts/fsl-ls1028a.dtsi > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index f48481f..8ecd095 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -20,6 +20,40 @@ config ARCH_LS1012A > select SYS_I2C_MXC_I2C2 > imply PANIC_HANG > > +config ARCH_LS1028A > + bool > + select ARMV8_SET_SMPEN > + select FSL_LSCH3 > + select NXP_LSCH3_2 > + select SYS_FSL_HAS_CCI400 > + select SYS_FSL_SRDS_1 > + select SYS_HAS_SERDES > + select SYS_FSL_DDR > + select SYS_FSL_DDR_LE > + select SYS_FSL_DDR_VER_50 > + select SYS_FSL_HAS_DDR3 > + select SYS_FSL_HAS_DDR4 > + select SYS_FSL_HAS_SEC > + select SYS_FSL_SEC_COMPAT_5 > + select SYS_FSL_SEC_LE > + select FSL_TZASC_1 > + select ARCH_EARLY_INIT_R > + select BOARD_EARLY_INIT_F > + select SYS_I2C_MXC > + select SYS_I2C_MXC_I2C1 > + select SYS_I2C_MXC_I2C2 > + select SYS_I2C_MXC_I2C3 > + select SYS_I2C_MXC_I2C4 > + select SYS_I2C_MXC_I2C5 > + select SYS_I2C_MXC_I2C6 > + select SYS_I2C_MXC_I2C7 > + select SYS_I2C_MXC_I2C8 > + select SYS_FSL_ERRATUM_A009007 > + select SYS_FSL_ERRATUM_A008514 if !TFABOOT > + select SYS_FSL_ERRATUM_A009663 if !TFABOOT > + select SYS_FSL_ERRATUM_A009942 if !TFABOOT > + imply PANIC_HANG > + > config ARCH_LS1043A > bool > select ARMV8_SET_SMPEN > @@ -244,6 +278,7 @@ config FSL_PCIE_COMPAT >
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
> -Original Message- > From: Peng Ma > Sent: Wednesday, March 27, 2019 2:53 PM > To: Prabhakar Kushwaha ; Shengzhou Liu > ; Ruchika Gupta > Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya > ; York Sun ; > bmeng...@gmail.com; s...@denx.de; m...@marvell.com; Andy Tang > ; u-boot@lists.denx.de; Peng Ma > Subject: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc > socs > > This patch is to support Freescale sata driver with dts initialized. > Also resolved the following problems. > > = WARNING == This board > does not use CONFIG_DM_SCSI. Please update the storage controller to use > CONFIG_DM_SCSI before the v2019.07 release. > Failure to update by the deadline may result in board removal. > See doc/driver-model/MIGRATION.txt for more info. > > > Signed-off-by: Peng Ma > --- > depends on: > - https://patchwork.ozlabs.org/project/uboot/list/?series=99168 > - https://patchwork.ozlabs.org/project/uboot/list/?series=99167 > > drivers/ata/Kconfig| 10 + > drivers/ata/Makefile |1 + > drivers/ata/fsl_ahci.c | 1030 > drivers/ata/fsl_sata.h |1 + > 4 files changed, 1042 insertions(+) > create mode 100644 drivers/ata/fsl_ahci.c > New driver is getting added in drivers/ata. I request driver/ata maintainer to review --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS
Dear Panto, Jaehoon > -Original Message- > From: Yinbo Zhu > Sent: Tuesday, March 26, 2019 2:38 PM > To: York Sun ; u-boot@lists.denx.de > Cc: Xiaobo Xie ; Ran Wang ; > Jiafei Pan ; Y.b. Lu ; Jagdish Gediya > ; Prabhakar Kushwaha > ; Yinbo Zhu > Subject: RE: [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS > > Hi, > > This patches set is for enable uboot DM for usb and sd on t2080qds, I haded > tested the io function. And I find that if the block size is less than 8, the > read > process will be hung, hung’s code is in blkcache_fill’s memcpy Function, and > when memcpy do “*dl++ = *sl++” operation then read process will be hung. but > fsl-layerscape uboot DM work well. ppc non-DM work well, it seems to be block > driver(CONFIG_BLK) issue related to PPC. Please you note. > Can you please check this observarion!! > Thanks > Best Regards, > Yinbo Zhu. > > -Original Message- > From: Yinbo Zhu [mailto:yinbo@nxp.com] > Sent: 2019年3月26日 11:09 > To: York Sun ; u-boot@lists.denx.de > Cc: Yinbo Zhu ; Xiaobo Xie ; Ran > Wang ; Jiafei Pan ; Y.b. Lu > ; Jagdish Gediya ; Prabhakar > Kushwaha > Subject: [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS > > >From: Yinbo Zhu > > >This patch is to enable MMC DM for T2080QDS in uboot > > >Signed-off-by: Yinbo Zhu > >--- > >configs/T2080QDS_NAND_defconfig | 3 +++ > >configs/T2080QDS_SDCARD_defconfig | 3 +++ > >configs/T2080QDS_SECURE_BOOT_defconfig| 3 +++ > >configs/T2080QDS_SPIFLASH_defconfig | 3 +++ > >configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 3 +++ > >configs/T2080QDS_defconfig| 3 +++ > >6 files changed, 18 insertions(+) > > >diff --git a/configs/T2080QDS_NAND_defconfig > >b/configs/T2080QDS_NAND_defconfig index 948a05af89..02d47c9fdd 100644 > >--- a/configs/T2080QDS_NAND_defconfig > >+++ b/configs/T2080QDS_NAND_defconfig > >@@ -59,3 +59,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SDCARD_defconfig > >b/configs/T2080QDS_SDCARD_defconfig > >index 30e87df3bb..4ce83fe8c4 100644 > >--- a/configs/T2080QDS_SDCARD_defconfig > >+++ b/configs/T2080QDS_SDCARD_defconfig > >@@ -58,3 +58,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SECURE_BOOT_defconfig > >b/configs/T2080QDS_SECURE_BOOT_defconfig > >index 2658bf8460..e2a7d3fa76 100644 > >--- a/configs/T2080QDS_SECURE_BOOT_defconfig > >+++ b/configs/T2080QDS_SECURE_BOOT_defconfig > >@@ -52,3 +52,6 @@ CONFIG_RSA_SOFTWARE_EXP=y CONFIG_OF_LIBFDT=y > >CONFIG_MPC85XX_HAVE_RESET_VECTOR=y > >CONFIG_DEFAULT_DEVICE_TREE="t2080qds" > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_OF_CONTROL=y > >diff --git a/configs/T2080QDS_SPIFLASH_defconfig > >b/configs/T2080QDS_SPIFLASH_defconfig > >index 0cccb3a85d..641f3c0c97 100644 > >--- a/configs/T2080QDS_SPIFLASH_defconfig > >+++ b/configs/T2080QDS_SPIFLASH_defconfig > >@@ -59,3 +59,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >b/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >index 8febabd84f..d2a8875aac 100644 > >--- a/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >+++ b/configs/T2080QDS_SRIO_PCIE_BOOT_defconfig > >@@ -42,3 +42,6 @@ CONFIG_OF_LIBFDT=y > >CONFIG_MPC85XX_HAVE_RESET_VECTOR=y > >CONFIG_OF_CONTROL=y > >CONFIG_DEFAULT_DEVICE_TREE="t2080qds" > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > >diff --git a/configs/T2080QDS_defconfig b/configs/T2080QDS_defconfig > >index 79cf4424b4..d55ce771a9 100644 > >--- a/configs/T2080QDS_defconfig > >+++ b/configs/T2080QDS_defconfig > >@@ -48,3 +48,6 @@ CONFIG_SPI=y > >CONFIG_FSL_ESPI=y > >CONFIG_USB=y > >>CONFIG_USB_STORAGE=y > >+CONFIG_DM_MMC=y > >+CONFIG_BLK=y > >+CONFIG_DM=y > -- > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] configs: enable usb device module in T2080QDS
> -Original Message- > From: Yinbo Zhu > Sent: Tuesday, March 26, 2019 8:43 AM > To: York Sun ; u-boot@lists.denx.de > Cc: Yinbo Zhu ; Xiaobo Xie ; Ran > Wang ; Jiafei Pan ; Y.b. Lu > ; Jagdish Gediya ; Prabhakar > Kushwaha > Subject: [PATCH v2 3/3] configs: enable usb device module in T2080QDS > > From: Yinbo Zhu > > This patch is to enable usb DM for T2080QDS in uboot > Please work on description --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS
> -Original Message- > From: Yinbo Zhu > Sent: Tuesday, March 26, 2019 8:39 AM > To: York Sun ; u-boot@lists.denx.de > Cc: Yinbo Zhu ; Xiaobo Xie ; Ran > Wang ; Jiafei Pan ; Y.b. Lu > ; Jagdish Gediya ; Prabhakar > Kushwaha > Subject: [PATCH v2 5/5] configs: enable eSDHC device module in T2080QDS > > From: Yinbo Zhu > > This patch is to enable MMC DM for T2080QDS in uboot Patch is for u-boot. No need to mention explicitly. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] misc: i2c_eeprom: add eeprom write support
Write up to page size in each i2c transfer.
Signed-off-by: Baruch Siach
---
drivers/misc/i2c_eeprom.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index ce2cad44d8d4..f25d0540075d 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -38,7 +39,24 @@ static int i2c_eeprom_std_read(struct udevice *dev, int
offset, uint8_t *buf,
static int i2c_eeprom_std_write(struct udevice *dev, int offset,
const uint8_t *buf, int size)
{
- return -ENODEV;
+ struct i2c_eeprom *priv = dev_get_priv(dev);
+ int ret;
+
+ while (size > 0) {
+ int write_size = min_t(int, size, priv->pagesize);
+
+ ret = dm_i2c_write(dev, offset, buf, write_size);
+ if (ret)
+ return ret;
+
+ offset += write_size;
+ buf += write_size;
+ size -= write_size;
+
+ udelay(1);
+ }
+
+ return 0;
}
static const struct i2c_eeprom_ops i2c_eeprom_std_ops = {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] misc: i2c_eeprom: support DT pagesize property
Read the page size from DT when available.
Signed-off-by: Baruch Siach
---
drivers/misc/i2c_eeprom.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index 29ad87c1d7b4..ce2cad44d8d4 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -50,6 +50,12 @@ static int i2c_eeprom_std_ofdata_to_platdata(struct udevice
*dev)
{
struct i2c_eeprom *priv = dev_get_priv(dev);
u64 data = dev_get_driver_data(dev);
+ u32 pagesize;
+
+ if (dev_read_u32(dev, "pagesize", ) == 0) {
+ priv->pagesize = pagesize;
+ return 0;
+ }
/* 6 bit -> page size of up to 2^63 (should be sufficient) */
priv->pagewidth = data & 0x3F;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] mmc: fsl_esdhc: ppc: set sdhc clock
> -Original Message-
> From: Yinbo Zhu
> Sent: Tuesday, March 26, 2019 8:39 AM
> To: York Sun ; u-boot@lists.denx.de
> Cc: Yinbo Zhu ; Xiaobo Xie ; Ran
> Wang ; Jiafei Pan ; Y.b. Lu
> ; Jagdish Gediya ; Prabhakar
> Kushwaha
> Subject: [PATCH v2 2/5] mmc: fsl_esdhc: ppc: set sdhc clock
>
> From: Yinbo Zhu
>
> This patch is to set sdhc clock for ppc
Can we get more description on this
>
> Signed-off-by: Yinbo Zhu
> ---
> drivers/mmc/fsl_esdhc.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 9e34557d16..a65e5c19db 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -1428,7 +1428,9 @@ void fdt_fixup_esdhc(void *blob, bd_t *bd) #endif
>
> #if CONFIG_IS_ENABLED(DM_MMC)
> +#ifndef CONFIG_PPC
> #include
> +#endif
> __weak void init_clk_usdhc(u32 index)
> {
> }
> @@ -1454,7 +1456,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
> if (addr == FDT_ADDR_T_NONE)
> return -EINVAL;
>
> - priv->esdhc_regs = (struct fsl_esdhc *)addr;
> + priv->esdhc_regs = (struct fsl_esdhc *)(addr);
Why this change is required?
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] i2c: mvtwsi: fix hang on SPL bind
The mvebu specific debug register is not accessible when the bind code
runs in SPL. Skip it.
Signed-off-by: Baruch Siach
---
drivers/i2c/mvtwsi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 74ac0a4aa789..05560e112729 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -801,6 +801,10 @@ static int mvtwsi_i2c_ofdata_to_platdata(struct udevice
*bus)
static void twsi_disable_i2c_slave(struct mvtwsi_registers *twsi)
{
+ /* The debug register is not accessible in early boot */
+ if (IS_ENABLED(CONFIG_SPL_BUILD))
+ return;
+
clrbits_le32(>debug, BIT(18));
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] configs: ls1046: Update mtd-id for QSPI nor in mtdparts variable
Hi Kuldeep,
> -Original Message-
> From: U-Boot On Behalf Of Prabhakar
> Kushwaha
> Sent: Friday, March 22, 2019 4:30 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Mingkai Hu
>
> Subject: Re: [U-Boot] [PATCH v3] configs: ls1046: Update mtd-id for QSPI nor
> in
> mtdparts variable
>
>
> > -Original Message-
> > From: Kuldeep Singh
> > Sent: Friday, March 8, 2019 3:08 PM
> > To: u-boot@lists.denx.de
> > Cc: Rajesh Bhagat ; Prabhakar Kushwaha
> > ; Ashish Kumar ;
> > Jagdish Gediya ; Mingkai Hu
> > ; Ruchika Gupta ; Kuldeep
> > Singh
> > Subject: [PATCH v3] configs: ls1046: Update mtd-id for QSPI nor in
> > mtdparts variable
> >
> > Update mtd-id for QSPI nor due to change introduced in mtd/spi in
> > linux 5.0
> >
> > commit 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI
> > controller")
> >
> > Signed-off-by: Kuldeep Singh
> > ---
> > v3:
> > Update commit message
> >
> > v2:
> > Update commit message
> >
> > configs/ls1046aqds_qspi_defconfig | 4 ++--
> > configs/ls1046aqds_sdcard_qspi_defconfig| 4 ++--
> > configs/ls1046ardb_emmc_defconfig | 4 ++--
> > configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 4 ++--
> > configs/ls1046ardb_qspi_defconfig | 4 ++--
> > configs/ls1046ardb_qspi_spl_defconfig | 4 ++--
> > configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 4 ++--
> > configs/ls1046ardb_sdcard_defconfig | 4 ++--
> > configs/ls1046ardb_tfa_SECURE_BOOT_defconfig| 4 ++--
> > configs/ls1046ardb_tfa_defconfig| 4 ++--
> > 10 files changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/configs/ls1046aqds_qspi_defconfig
> > b/configs/ls1046aqds_qspi_defconfig
> > index 4cc19fe7ac..b7a6da2128 100644
> > --- a/configs/ls1046aqds_qspi_defconfig
> > +++ b/configs/ls1046aqds_qspi_defconfig
> > @@ -10,7 +10,7 @@ CONFIG_OF_BOARD_SETUP=y CONFIG_QSPI_BOOT=y
> > CONFIG_BOOTDELAY=10
> > CONFIG_USE_BOOTARGS=y
> > -CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> > earlycon=uart8250,mmio,0x21c0500
> > mtdparts=155.quadspi:2m(uboot),14m(free)"
> > +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> > earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-
> > 0:2m(uboot),14m(free)"
>
> How backward Linux compatibility is being taken care?
>
Please respond to this query otherwise, I am going to drop this patch
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting from network
Am 07.04.2019 um 01:22 schrieb Chris Packham:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, wrote:
I'm booting over the network (GbE) from a tftp server.
It works, but is IMHO very slow.
Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
There were some patches for wget on the list (implementing TCP, HTTP and
wget command), but I don't think they were in a state to be accepted, so
yes, TFTP is pretty much the only option here.
Because TFTP sends a block at a time waiting for an ack between blocks it's
not going to be as fast as something that runs over TCP and benefits from
buffering.
Depending on what stability you need: I saw some TFTP servers (the one
included in www.dhcpserver.de, for example) in the past that sent out
some packets in advance (before waiting for the client's ACK). That
improves speed pretty well, but the downside is that retransmission
handling is pretty much broken. For my purposes (no transmission
problems on the local net), this is still a good enough solution to get
higher transmission speed. I wouldn't want to use this in a production
setup though...
Regards,
Simon
One tunable you might get some use out of is $tftpblocksize, this will
increase the number of bytes per block. Try setting this to around 1400
keeping the overall Ethernet frame under 1518.
boot.cmd:
dhcp 0x4900
tftpboot 0x4600 192.168.1.201:uImage
tftpboot 0x4900 192.168.1.201:u-boot.dtb
setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
rootfstype=ext4 rw ${extra}
bootm 0x4600 - 0x4900
Btw, in the above script, can I safely replace the addresses
with ${kloadaddr} and ${fdtaddr} ?
I wonder where these variables get set or obtained from.
(I saw these variables somewhere on the net, but there was no
initialisation,
so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize.
The latter two are set after a successful load. However plenty of boards
have $fdtaddr etc in their default environment so you might have acces to
those depending on your board.
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment.
Is there another method to get the u-boot output (or log) to be sent to a
remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its
only good for output.
I'd still recommend getting a serial cable if your going to be playing with
u-boot becasue at some point you'll do something that stops your board from
booting.
___
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
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
On 06/04/2019 22:41, Breno Matheus Lima wrote: Hi Bryan, Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue escreveu: On 05/04/2019 17:16, Breno Matheus Lima wrote: Basically you've described and additional dependency the BootROM has, so lets just "switch context" prior to calling into the BootROM and restore to a default non-secure job-ring assignment after. Yes, this can work for OP-TEE users decrypting additional boot images at U-Boot level, however all users won't be able to authenticate/decrypt the initial boot image at BootROM level. I don't understand that comment, perhaps you can give an example. Out of reset CAAM job rings are assigned to TrustZone secure world and BootROM code is expecting blobs generated by the same environment. What about moving the job rings assignment to OP-TEE level? Something similar as we currently have in imx-optee-os project? TBH, I see that as something that should be done _anyway_ not instead i.e. after u-boot, if you want to do 'stuff' with the CAAM you are either 1. Running in non-secure Linux, in which case you need the job-rings assigned to non-secure mode or 2. You are running inside of a TEE, in which case you absolutely need to have at least one job-ring ... and for the second case the right thing to do is to arbitrate ownership of job-rings via a DTB https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31 U-Boot is running in TrustZone secure world in most of targets, in my opinion it makes sense to have at least 1 job ring assigned to TrustZone secure world. But if u-boot is running in secure-world save_jr_context(); setup_some_new_jr_context(); hab_authenticate_something(); restore_jr_context(); As a "quick fix", that's the way I'd do it. Just pivoting on CONFIG_OPTEE is pretty easy to break i.e. you can have CONFIG_OPTEE defined in your u-boot config but not actually be executing a TEE, in which case by the time you boot Linux your JR assignment is wrong.. The correct and flexible fix is passing a DTB descriptor that u-boot, OPTEE and Kernel can put data into so that there's a canonical description of which execution environment owns what. --- bod ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
