Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()
On 07.06.20 20:42, Heinrich Schuchardt wrote: On 6/6/20 11:13 PM, Heinrich Schuchardt wrote: Functions __raw_writeq(), __raw_readq() are available for all architectures. So let's use them. The major architectures have these but not m68k, microblaze, nd32, nios2, powerpc, sh, xtenza. Just checking to be clear: This patch breaks compiling on these platforms and you are withdrawing it (for now)? Thanks, Stefan Signed-off-by: Heinrich Schuchardt --- drivers/mtd/cfi_flash.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index b7289ba539..e31e07ca80 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void *addr) __maybe_weak void flash_write64(u64 value, void *addr) { - /* No architectures currently implement __raw_writeq() */ - *(volatile u64 *)addr = value; + __raw_writeq(value, addr); } __maybe_weak u8 flash_read8(void *addr) @@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr) __maybe_weak u64 flash_read64(void *addr) { - /* No architectures currently implement __raw_readq() */ - return *(volatile u64 *)addr; + return __raw_readq(addr); } /*--- -- 2.26.2 Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()
On 6/8/20 9:07 AM, Stefan Roese wrote: > On 07.06.20 20:42, Heinrich Schuchardt wrote: >> On 6/6/20 11:13 PM, Heinrich Schuchardt wrote: >>> Functions __raw_writeq(), __raw_readq() are available for all >>> architectures. So let's use them. >> >> The major architectures have these but not m68k, microblaze, nd32, >> nios2, powerpc, sh, xtenza. > > Just checking to be clear: This patch breaks compiling on these > platforms and you are withdrawing it (for now)? Yes, it breaks compiling on the specified platforms. This can be fixed by adding the missing functions to the platforms: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commits/sunxi But is it worthwhile to add __raw_writeq(), __raw_readq() to all of these? Best regards Heinrich > > Thanks, > Stefan > >>> >>> Signed-off-by: Heinrich Schuchardt >>> --- >>> drivers/mtd/cfi_flash.c | 6 ++ >>> 1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c >>> index b7289ba539..e31e07ca80 100644 >>> --- a/drivers/mtd/cfi_flash.c >>> +++ b/drivers/mtd/cfi_flash.c >>> @@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void >>> *addr) >>> >>> __maybe_weak void flash_write64(u64 value, void *addr) >>> { >>> - /* No architectures currently implement __raw_writeq() */ >>> - *(volatile u64 *)addr = value; >>> + __raw_writeq(value, addr); >>> } >>> >>> __maybe_weak u8 flash_read8(void *addr) >>> @@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr) >>> >>> __maybe_weak u64 flash_read64(void *addr) >>> { >>> - /* No architectures currently implement __raw_readq() */ >>> - return *(volatile u64 *)addr; >>> + return __raw_readq(addr); >>> } >>> >>> >>> /*--- >>> >>> -- >>> 2.26.2 >>> >> > > > Viele Grüße, > Stefan >
Pull request: u-boot-rockchip-20200607
Hi Tom, Please pull the rockchip updates/fixes: - revive rk3399 puma board to adapt mainline dts; - Fix rk3399-evb stdout path; - Enable PCIe for rk3399: Rockpro64, firefly, pinebookpro; - Add rk3328 Rock-pi-e board; - Enable SPI boot for rockpro64 and roc-pc-rk3399; Gitlab ci: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3580 Thanks, - Kever The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140: configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20200607 for you to fetch changes up to 187ab38e766393cda7bf3bf4926c1e55f48ad0cb: rockchip: enable PCIe and NVMe on Pinebook Pro (2020-06-07 20:53:23 +0800) Heiko Stuebner (8): arm64: dts: rk3399-puma: fix gpio levels for gmac reset pin arm64: dts: rk3399-puma: fix gpio levels for vcc5v0-host regulator rockchip: puma: fix indentation for -u-boot.dtsi rockchip: puma: fix indentation of misc_init_r rockchip: puma: reorganize devicetrees to actually work and match upstream rockchip: puma: remove separate fit generator rockchip: puma: drop special handling of usb host regulator rockchip: puma: enable new usb config options Jagan Teki (4): Makefile: Drop to handle rkspi image type roc-rk3399-pc: Mark default env from SPI roc-rk3399-pc: Add SPI boot doc: rockchip: Document SPI flash program steps Kever Yang (1): rockchip: rk3399-evb: add stdout-path for the board Marcin Juszkiewicz (2): rockchip: rockpro64: Store default env into SPI rockchip: rockpro64: add SPI boot Mark Kettenis (2): rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399 rockchip: Enable PCIe and NVMe on ROCKPro64 Patrick Wildt (1): rockchip: enable PCIe and NVMe on Pinebook Pro b.l.huang (2): rockchip: rk3328: add rock-pi-e dts file rockchip: rk3328: add rock-pi-e-rk3328_defconfig file Makefile | 11 +- arch/arm/dts/Makefile | 7 +- arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 33 +++ arch/arm/dts/rk3328-rock-pi-e.dts | 267 arch/arm/dts/rk3399-evb-u-boot.dtsi| 1 + arch/arm/dts/rk3399-puma-ddr1333-u-boot.dtsi | 4 - arch/arm/dts/rk3399-puma-ddr1333.dts | 8 - arch/arm/dts/rk3399-puma-ddr1600-u-boot.dtsi | 4 - arch/arm/dts/rk3399-puma-ddr1600.dts | 9 - arch/arm/dts/rk3399-puma-ddr1866-u-boot.dtsi | 4 - arch/arm/dts/rk3399-puma-ddr1866.dts | 8 - ...-u-boot.dtsi => rk3399-puma-haikou-u-boot.dtsi} | 43 ++-- arch/arm/dts/rk3399-puma-haikou.dts| 271 + arch/arm/dts/rk3399-puma.dtsi | 4 +- arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 +- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 12 +- board/rockchip/evb_rk3328/MAINTAINERS | 7 + board/theobroma-systems/puma_rk3399/Kconfig| 15 ++ board/theobroma-systems/puma_rk3399/fit_spl_atf.sh | 94 --- board/theobroma-systems/puma_rk3399/puma-rk3399.c | 93 +-- configs/firefly-rk3399_defconfig | 4 + configs/pinebook-pro-rk3399_defconfig | 4 + configs/puma-rk3399_defconfig | 8 +- configs/roc-pc-mezzanine-rk3399_defconfig | 9 +- configs/roc-pc-rk3399_defconfig| 9 +- configs/rock-pi-e-rk3328_defconfig | 104 configs/rockpro64-rk3399_defconfig | 10 +- doc/board/rockchip/rockchip.rst| 27 +- include/configs/roc-pc-rk3399.h| 4 - include/configs/rockpro64_rk3399.h | 2 - 30 files changed, 830 insertions(+), 258 deletions(-) create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts delete mode 100644 arch/arm/dts/rk3399-puma-ddr1333-u-boot.dtsi delete mode 100644 arch/arm/dts/rk3399-puma-ddr1333.dts delete mode 100644 arch/arm/dts/rk3399-puma-ddr1600-u-boot.dtsi delete mode 100644 arch/arm/dts/rk3399-puma-ddr1600.dts delete mode 100644 arch/arm/dts/rk3399-puma-ddr1866-u-boot.dtsi delete mode 100644 arch/arm/dts/rk3399-puma-ddr1866.dts rename arch/arm/dts/{rk3399-puma-u-boot.dtsi => rk3399-puma-haikou-u-boot.dtsi} (53%) create mode 100644 arch/arm/dts/rk3399-puma-haikou.dts delete mode 100755 board/theobroma-systems/puma_rk3399/fit_spl_atf.sh create mode 100644 configs/rock-pi-e-rk3328_defconfig
Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()
On 08.06.20 09:12, Heinrich Schuchardt wrote: On 6/8/20 9:07 AM, Stefan Roese wrote: On 07.06.20 20:42, Heinrich Schuchardt wrote: On 6/6/20 11:13 PM, Heinrich Schuchardt wrote: Functions __raw_writeq(), __raw_readq() are available for all architectures. So let's use them. The major architectures have these but not m68k, microblaze, nd32, nios2, powerpc, sh, xtenza. Just checking to be clear: This patch breaks compiling on these platforms and you are withdrawing it (for now)? Yes, it breaks compiling on the specified platforms. This can be fixed by adding the missing functions to the platforms: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commits/sunxi But is it worthwhile to add __raw_writeq(), __raw_readq() to all of these? Sure, why not? Thanks, Stefan Best regards Heinrich Thanks, Stefan Signed-off-by: Heinrich Schuchardt --- drivers/mtd/cfi_flash.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index b7289ba539..e31e07ca80 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void *addr) __maybe_weak void flash_write64(u64 value, void *addr) { - /* No architectures currently implement __raw_writeq() */ - *(volatile u64 *)addr = value; + __raw_writeq(value, addr); } __maybe_weak u8 flash_read8(void *addr) @@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr) __maybe_weak u64 flash_read64(void *addr) { - /* No architectures currently implement __raw_readq() */ - return *(volatile u64 *)addr; + return __raw_readq(addr); } /*--- -- 2.26.2 Viele Grüße, Stefan Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
pull request of u-boot-mpc85xx for v2020.07
Dear Tom, Please find my pull-request for u-boot-mpc85xx https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/694639674 Summary DM_ETH support for P2041RDB, T1024RDB, P5040DS, P3041DS, P4080DS, bug fixes Add TBI Phy access through MII DDR: Rework errata workaround for A008109, A008378, 009942 Thanks Priyanka - The following changes since commit ecd4d99f654f3f7bfb96001891d69c3125e70b69: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2020-06-01 23:34:18 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx.git HEAD for you to fetch changes up to 164a5af43635c63ea2459d4c87a1a4b16acd689a: ddr: Rework errata A008109, A008378, 009942 workaround (2020-06-04 18:53:20 +0530) Hou Zhiqiang (3): doc: dt-bindings: tsec: Correct the Ethernet port compatible string net: tsec: Access eTSEC registers using virtual address net: tsec: Access TBI PHY through the corresponding MII Jaiprakash Singh (1): ddr: Rework errata A008109, A008378, 009942 workaround Joakim Tjernlund (1): ddr: fsl: Impl. Erratum A008109 Madalin Bucur (22): drivers: net: e1000: with DM_ETH needs DM_PCI too powerpc/mpc85xx: Fix compiling error with DM_GPIO powerpc: mpc85xx: fix unused variable warning drivers: net: qe: deselect QE when DM_ETH is enabled board/freescale: add the DM_ETH changes for the PPC DPAA platforms net: tsec: fsl_mdio: add DM MDIO support powerpc: dts: QorIQ: Add node(s) for the platform PLL powerpc: dts: add QorIQ GPIOs powerpc: dts: add QorIQ DPAA 1 FMan device tree nodes powerpc: dts: add QorIQ DPAA 1 FMan v3 device tree nodes powerpc: dts: add QorIQ DPAA 1 FMan for P4080 powerpc: dts: add QorIQ DPAA 1 FMan interfaces to P4080DS powerpc: dts: add QorIQ DPAA 1 FMan for P2041 powerpc: dts: add QorIQ DPAA 1 FMan to P2041RDB powerpc: dts: add QorIQ DPAA 1 FMan for P3041 powerpc: dts: add QorIQ DPAA 1 FMan to P3041DS powerpc: dts: add QorIQ DPAA 1 FMan for P5040 powerpc: dts: add QorIQ DPAA 1 FMan to P5040DS powerpc: dts: add QorIQ DPAA 1 FMan v3 for T102x powerpc: dts: add QorIQ DPAA 1 FMan v3 to T1024RDB configs: enable DM_ETH support for P2041RDB configs: enable DM_ETH support for T1024RDB arch/powerpc/cpu/mpc85xx/Kconfig | 6 + arch/powerpc/cpu/mpc85xx/cpu_init.c| 6 +- arch/powerpc/dts/p2041rdb.dts | 98 +++- arch/powerpc/dts/p2041si-post.dtsi | 42 arch/powerpc/dts/p3041ds.dts | 129 ++- arch/powerpc/dts/p3041si-post.dtsi | 42 arch/powerpc/dts/p4080ds.dts | 191 +++- arch/powerpc/dts/p4080si-post.dtsi | 61 + arch/powerpc/dts/p5040ds.dts | 252 - arch/powerpc/dts/p5040si-post.dtsi | 69 ++ arch/powerpc/dts/qoriq-clockgen1.dtsi | 14 ++ arch/powerpc/dts/qoriq-clockgen2.dtsi | 14 ++ arch/powerpc/dts/qoriq-fman-0-10g-0.dtsi | 37 +++ arch/powerpc/dts/qoriq-fman-0-1g-0.dtsi| 44 arch/powerpc/dts/qoriq-fman-0-1g-1.dtsi| 43 arch/powerpc/dts/qoriq-fman-0-1g-2.dtsi| 43 arch/powerpc/dts/qoriq-fman-0-1g-3.dtsi| 43 arch/powerpc/dts/qoriq-fman-0-1g-4.dtsi| 43 arch/powerpc/dts/qoriq-fman-0.dtsi | 79 +++ arch/powerpc/dts/qoriq-fman-1-10g-0.dtsi | 36 +++ arch/powerpc/dts/qoriq-fman-1-1g-0.dtsi| 43 arch/powerpc/dts/qoriq-fman-1-1g-1.dtsi| 43 arch/powerpc/dts/qoriq-fman-1-1g-2.dtsi| 43 arch/powerpc/dts/qoriq-fman-1-1g-3.dtsi| 43 arch/powerpc/dts/qoriq-fman-1-1g-4.dtsi| 43 arch/powerpc/dts/qoriq-fman-1.dtsi | 79 +++ .../dts/qoriq-fman3-0-10g-0-best-effort.dtsi | 47 arch/powerpc/dts/qoriq-fman3-0-10g-0.dtsi | 44 .../dts/qoriq-fman3-0-10g-1-best-effort.dtsi | 47 arch/powerpc/dts/qoriq-fman3-0-10g-1.dtsi | 44 arch/powerpc/dts/qoriq-fman3-0-1g-0.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0-1g-1.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0-1g-2.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0-1g-3.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0-1g-4.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0-1g-5.dtsi | 43 arch/powerpc/dts/qoriq-fman3-0.dtsi| 84 +++ arch/powerpc/dts/qoriq-fman3-1-10g-0.dtsi | 44 arch/powerpc/dts/qoriq-fman3-1-10g-1.dtsi | 44 arch/powerpc/dts/qoriq-fman3-1-1g-0.dtsi | 43 arch/
RE: [PATCHv2 3/3] net: tsec: Access TBI PHY through the corresponding MII
>-Original Message- >From: U-Boot On Behalf Of Zhiqiang Hou >Sent: Sunday, May 3, 2020 8:19 PM >To: u-boot@lists.denx.de; joe.hershber...@ni.com; bmeng...@gmail.com; >olte...@gmail.com; Priyanka Jain >Cc: Z.q. Hou >Subject: [PATCHv2 3/3] net: tsec: Access TBI PHY through the corresponding >M II > >From: Hou Zhiqiang > >When an eTSEC is configured to use TBI, configuration of the TBI is done >through the MIIM registers for that eTSEC. >For example, if a TBI interface is required on eTSEC2, then the MIIM registers >starting at offset 0x2_5520 are used to configure it. > >Fixes: 9a1d6af55ecd ("net: tsec: Add driver model ethernet support") >Signed-off-by: Hou Zhiqiang >Reviewed-by: Vladimir Oltean >Tested-by: Vladimir Oltean >--- Series applied on mpc85xx. Awaiting upstream Thanks Priyanka
RE: [PATCH] drivers: net: e1000: with DM_ETH needs DM_PCI too
>-Original Message- >From: U-Boot On Behalf Of Madalin Bucur >Sent: Wednesday, April 29, 2020 10:56 AM >To: joe.hershber...@ni.com; u-boot@lists.denx.de >Cc: Madalin Bucur (OSS) >Subject: [PATCH] drivers: net: e1000: with DM_ETH needs DM_PCI too > >Compilation error occur when DM_ETH is enabled without DM_PCI. > >Signed-off-by: Madalin Bucur >--- Patch applied on mpc85xx. Awaiting upstream Thanks Priyanka
RE: [PATCH] powerpc/mpc85xx: Fix compiling error with DM_GPIO
>-Original Message- >From: U-Boot On Behalf Of Madalin Bucur >Sent: Wednesday, April 29, 2020 11:04 AM >To: w...@denx.de; u-boot@lists.denx.de >Cc: Madalin Bucur (OSS) >Subject: [PATCH] powerpc/mpc85xx: Fix compiling error with DM_GPIO > >P4080DS compilation fails with DM_GPIO enabled: > >drivers/gpio/gpio-uclass.c:355:5: error: redefinition of 'gpio_request' > int gpio_request(unsigned gpio, const char *label) > ^~~~ >In file included from ./arch/powerpc/include/asm/arch/gpio.h:17:0, > from ./arch/powerpc/include/asm/gpio.h:1, > from drivers/gpio/gpio-uclass.c:16: >./arch/powerpc/include/asm/mpc85xx_gpio.h:68:19: note: previous >definition of 'gpio_request' was here static inline int gpio_request(unsigned >gpio, const char *label) > ^~~~ > >Signed-off-by: Madalin Bucur >--- Patch applied on mpc85xx. Awaiting upstream Thanks Priyanka
RE: [PATCH] powerpc: mpc85xx: fix unused variable warning
>-Original Message- >From: U-Boot On Behalf Of Madalin Bucur >Sent: Wednesday, April 29, 2020 2:47 PM >To: Priyanka Jain ; w...@denx.de; u- >b...@lists.denx.de >Cc: Madalin Bucur (OSS) >Subject: [PATCH] powerpc: mpc85xx: fix unused variable warning > >Fix unused variable warning when CONFIG_QE is not set. > >Signed-off-by: Madalin Bucur >--- Patch applied on mpc85xx. Awaiting upstream Thanks Priyanka
RE: [PATCH] drivers: net: qe: deselect QE when DM_ETH is enabled
>-Original Message- >From: U-Boot On Behalf Of Madalin Bucur >Sent: Wednesday, April 29, 2020 2:57 PM >To: Priyanka Jain ; u-boot@lists.denx.de >Cc: Madalin Bucur (OSS) >Subject: [PATCH] drivers: net: qe: deselect QE when DM_ETH is enabled > >A compilation error appears when QE is compiled with DM_ETH >enabled: > >drivers/qe/uec.c: In function 'init_phy': >drivers/qe/uec.c:425:28: error: dereferencing pointer to incomplete type >'struct eth_device' > uec = (uec_private_t *)dev->priv; >^~ >drivers/qe/uec.c: In function 'uec_initialize': >drivers/qe/uec.c:1357:43: error: invalid application of 'sizeof' to incomplete >type 'struct eth_device' > dev = (struct eth_device *)malloc(sizeof(struct eth_device)); > ^~ > >The patch disables CONFIG_QE when CONFIG_DM_ETH is set. > >Signed-off-by: Madalin Bucur >--- Patch applied on mpc85xx. Awaiting upstream Thanks Priyanka
Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
Hi, On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote: > The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any > additional drivers marked as DM_FLAG_PRE_RELOC are loaded before > relocation. > > CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image > verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. > > CONFIG_LOG=Y is another setting requiring additional early malloc > area, cf. log_init(). > > When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled > we see as output in main U-Boot > > alloc_simple() alloc space exhausted > > With this patch the default values of SYS_MALLOC_F_LEN and > SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. > > Signed-off-by: Heinrich Schuchardt Where is this SYS_MALLOC_F_LEN allocated from (in particular for the SPL). Is it from the SRAM? If so, on older SoCs, we probably don't have 8k to spare. Maxime signature.asc Description: PGP signature
Re: rockchip: correctly set vop0 or vop1
Patrick Wildt writes: Hi, > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or > vop1, but so far we have set it in both conditions, which is not > correct. > > Can someone verify this is the correct way round? vop1 -> set, > vop0 -> clear? > > Signed-off-by: Patrick Wildt > > diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c > index 92188be9275..000bd481408 100644 > --- a/drivers/video/rockchip/rk_edp.c > +++ b/drivers/video/rockchip/rk_edp.c > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev) > rk_setreg(&priv->grf->soc_con12, 1 << 4); > > /* select epd signal from vop0 or vop1 */ > - rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5)); > + rk_clrsetreg(&priv->grf->soc_con6, (1 << 5), > + (vop_id == 1) ? (1 << 5) : (0 << 5)); While working on PBP EDP support, found this too but I'm not sure it's fine or not. For rk3399, my (not yet published) patch is doing: + if (vop_id == 0) + rk_clrreg(&priv->grf->soc_con20, (1 << 5)); + else + rk_setreg(&priv->grf->soc_con20, (1 << 5)); I believe that the rk3288 may need similar treatment but I've yet to look at the rk3288 manual. Arnaud
[PATCH 2/3] arm64: lx2160a: dts: Add watchdog node
From: Zhao Qiang Add watchdog node which is sbsa into lx2160a dtsi Signed-off-by: Zhao Qiang --- arch/arm/dts/fsl-lx2160a.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi index 1789da8..a2421f6 100644 --- a/arch/arm/dts/fsl-lx2160a.dtsi +++ b/arch/arm/dts/fsl-lx2160a.dtsi @@ -204,6 +204,13 @@ #interrupt-cells = <2>; }; + watchdog@23a { + compatible = "arm,sbsa-gwdt"; + reg = <0x0 0x23a 0 0x1000>, + <0x0 0x239 0 0x1000>; + timeout-sec = <30>; + }; + usb0: usb3@310 { compatible = "fsl,layerscape-dwc3"; reg = <0x0 0x310 0x0 0x1>; -- 2.7.4
[PATCH 3/3] configs: lx2160a: Enable Watchdog support
From: Zhao Qiang Enable support to compile SBSA driver. Signed-off-by: Zhao Qiang --- configs/lx2160aqds_tfa_defconfig | 3 +++ configs/lx2160ardb_tfa_defconfig | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index 716c089..93e6a05 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y @@ -82,4 +83,6 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_WDT=y +CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index bc654cf..8504a50 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -30,6 +30,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y @@ -76,4 +77,6 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_WDT=y +CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y -- 2.7.4
[PATCH 1/3] Watchdog: introduce ARM SBSA watchdog driver
From: Zhao Qiang According to Server Base System Architecture (SBSA) specification, the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0) is for alerting the system by interrupt, the second one (WS1) is a real hardware reset. More details about the hardware specification of this device: ARM DEN0029B - Server Base System Architecture (SBSA) This driver can operate ARM SBSA Generic Watchdog as a single stage In the single stage mode, when the timeout is reached, your system will be reset by WS1. The first signal (WS0) is ignored. Signed-off-by: Zhao Qiang --- MAINTAINERS | 1 + drivers/watchdog/Kconfig | 6 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/sbsa_gwdt.c | 131 +++ 4 files changed, 139 insertions(+) create mode 100644 drivers/watchdog/sbsa_gwdt.c diff --git a/MAINTAINERS b/MAINTAINERS index 1fd975c..09554c0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -685,6 +685,7 @@ M: Priyanka Jain S: Maintained T: git https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git F: drivers/watchdog/sp805_wdt.c +F: drivers/watchdog/sbsa_gwdt.c I2C M: Heiko Schocher diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index bf06180..191891c 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -163,6 +163,12 @@ config WDT_SANDBOX can be probed and supports all of the methods of WDT, but does not really do anything. +config WDT_SBSA + bool "SBSA watchdog timer support" + depends on WDT + help + Select this to enable SBSA watchdog timer. + config WDT_SP805 bool "SP805 watchdog timer support" depends on WDT diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 519bbd3..0f0b2eb 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o obj-$(CONFIG_WDT_MTK) += mtk_wdt.o obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o +obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o obj-$(CONFIG_WDT_SP805) += sp805_wdt.o obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c new file mode 100644 index 000..99acb89 --- /dev/null +++ b/drivers/watchdog/sbsa_gwdt.c @@ -0,0 +1,131 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Watchdog driver for SBSA + * + * Copyright 2019 NXP + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +/* SBSA Generic Watchdog register definitions */ +/* refresh frame */ +#define SBSA_GWDT_WRR 0x000 + +/* control frame */ +#define SBSA_GWDT_WCS 0x000 +#define SBSA_GWDT_WOR 0x008 +#define SBSA_GWDT_WCV 0x010 + +/* refresh/control frame */ +#define SBSA_GWDT_W_IIDR 0xfcc +#define SBSA_GWDT_IDR 0xfd0 + +/* Watchdog Control and Status Register */ +#define SBSA_GWDT_WCS_EN BIT(0) +#define SBSA_GWDT_WCS_WS0 BIT(1) +#define SBSA_GWDT_WCS_WS1 BIT(2) + +struct sbsa_gwdt_priv { + void __iomem *reg_refresh; + void __iomem *reg_control; +}; + +static int sbsa_gwdt_reset(struct udevice *dev) +{ + struct sbsa_gwdt_priv *priv = dev_get_priv(dev); + + writel(0, priv->reg_refresh + SBSA_GWDT_WRR); + + return 0; +} + +static int sbsa_gwdt_start(struct udevice *dev, u64 timeout, ulong flags) +{ + u32 clk; + u32 load_value; + + struct sbsa_gwdt_priv *priv = dev_get_priv(dev); + /* +* it work in the single stage mode in u-boot, +* The first signal (WS0) is ignored, +* the timeout is (WOR * 2), so the WOR should be configured +* to half value of timeout. +*/ + clk = get_tbclk(); + writel(clk / 2 * timeout, + priv->reg_control + SBSA_GWDT_WOR); + + /* writing WCS will cause an explicit watchdog refresh */ + writel(SBSA_GWDT_WCS_EN, priv->reg_control + SBSA_GWDT_WCS); + + return 0; +} + +static int sbsa_gwdt_stop(struct udevice *dev) +{ + struct sbsa_gwdt_priv *priv = dev_get_priv(dev); + + writel(0, priv->reg_control + SBSA_GWDT_WCS); + + return 0; +} + +static int sbsa_gwdt_expire_now(struct udevice *dev, ulong flags) +{ + sbsa_gwdt_start(dev, 0, flags); + + return 0; +} + +static int sbsa_gwdt_probe(struct udevice *dev) +{ + debug("%s: Probing wdt%u (sbsa-gwdt)\n", __func__, dev->seq); + + return 0; +} + +static int sbsa_gwdt_ofdata_to_platdata(struct udevice *dev) +{ + struct sbsa_gwdt_priv *priv = dev_get_priv(dev); + + priv->reg_control = (void __iomem *)dev_read_addr_index(dev, 0); + if (IS_ERR(priv->reg_control)) + return PTR_ERR(priv->reg_control); + + priv->reg_refresh = (void __iomem *)dev_read_addr_index(dev, 1); + if
Re: [PATCH] regmap: Check for out-of-range offsets before mapping them
Hi Simon, On 07/06/20 08:43PM, Simon Glass wrote: > Hi Pratyush, > > On Tue, 26 May 2020 at 06:06, Pratyush Yadav wrote: > > > > In regmap_raw_{read,write}_range(), offsets are checked to make sure > > they aren't out of range. But this check happens _after_ the address is > > mapped from physical memory. Input should be sanity-checked before using > > it. Mapping the address before validating it leaves the door open to > > passing an invalid address to map_physmem(). So check for out of range > > offsets _before_ mapping them. > > > > This fixes a segmentation fault in sandbox when -1 is used as an offset > > to regmap_{read,write}(). > > > > Signed-off-by: Pratyush Yadav > > --- > > drivers/core/regmap.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Reviewed-by: Simon Glass Thanks. > Please add a sandbox test to catch this problem. The test "dm_test_devm_regmap" proposed in [0] should catch this: ut_asserteq(-ERANGE, regmap_write(priv->cfg_regmap, -1, val)); ut_asserteq(-ERANGE, regmap_read(priv->cfg_regmap, -1, &val)); [0] https://patchwork.ozlabs.org/project/uboot/patch/20200605203025.15466-9-p.ya...@ti.com/ -- Regards, Pratyush Yadav Texas Instruments India
Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
On 08/06/2020 09:02, Maxime Ripard wrote: > Hi, > > On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote: >> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any >> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before >> relocation. >> >> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image >> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. >> >> CONFIG_LOG=Y is another setting requiring additional early malloc >> area, cf. log_init(). >> >> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled >> we see as output in main U-Boot >> >> alloc_simple() alloc space exhausted >> >> With this patch the default values of SYS_MALLOC_F_LEN and >> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. Heinrich, many thanks for the debugging and the nice solution! >> >> Signed-off-by: Heinrich Schuchardt > > Where is this SYS_MALLOC_F_LEN allocated from (in particular for the > SPL). Is it from the SRAM? This is the value for U-Boot proper only, so it's taken from DRAM. There is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the SPL is safe. Cheers, Andre > > If so, on older SoCs, we probably don't have 8k to spare. > > Maxime >
[PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration
Add configuration flag to select the supported dwc driver configuration: - CONFIG_DWC_ETH_QOS_TEGRA186 - CONFIG_DWC_ETH_QOS_IMX - CONFIG_DWC_ETH_QOS_STM32 See Linux driver ethernet/stmicro/stmmac and associated glue layers for other configuration examples. This patch removes the not-selected compatibles and lets the linker remove the unused functions to reduce the size of the driver. Signed-off-by: Patrick Delaunay --- Hi, I propose this patch after Marek's remark in [1]. It is also linked to [2] to limit the STM32 glue for ST compatible. [1] net: dwc_eth_qos: Make clk_rx and clk_tx optional http://patchwork.ozlabs.org/project/uboot/patch/20200512095603.29126-5-david...@rock-chips.com/#2432595 [2] net: dwc_eth_qos: update the compatible supported for STM32 http://patchwork.ozlabs.org/project/uboot/list/?series=176917 drivers/net/Kconfig | 27 --- drivers/net/dwc_eth_qos.c | 12 +--- 2 files changed, 33 insertions(+), 6 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 0b08de0ef4..c4b3667d3b 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -156,9 +156,30 @@ config DWC_ETH_QOS help This driver supports the Synopsys Designware Ethernet QOS (Quality Of Service) IP block. The IP supports many options for bus type, - clocking/reset structure, and feature list. This driver currently - supports the specific configuration used in NVIDIA's Tegra186 chip, - but should be extensible to other combinations quite easily. + clocking/reset structure, and feature list. + +config DWC_ETH_QOS_IMX + bool "Synopsys DWC Ethernet QOS device support for IMX" + depends on DWC_ETH_QOS + help + The Synopsys Designware Ethernet QOS IP block with the specific + configuration used in IMX soc. + +config DWC_ETH_QOS_STM32 + bool "Synopsys DWC Ethernet QOS device support for STM32" + depends on DWC_ETH_QOS + default y if ARCH_STM32MP + help + The Synopsys Designware Ethernet QOS IP block with the specific + configuration used in STM32MP soc. + +config DWC_ETH_QOS_TEGRA186 + bool "Synopsys DWC Ethernet QOS device support for TEGRA186" + depends on DWC_ETH_QOS + default y if TEGRA186 + help + The Synopsys Designware Ethernet QOS IP block with specific + configuration used in NVIDIA's Tegra186 chip. config E1000 bool "Intel PRO/1000 Gigabit Ethernet support" diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index 3f4437069b..d4536a325f 100644 --- a/drivers/net/dwc_eth_qos.c +++ b/drivers/net/dwc_eth_qos.c @@ -2100,7 +2100,7 @@ static struct eqos_ops eqos_tegra186_ops = { .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_tegra186 }; -static const struct eqos_config eqos_tegra186_config = { +static const struct eqos_config __maybe_unused eqos_tegra186_config = { .reg_access_always_ok = false, .mdio_wait = 10, .swr_wait = 10, @@ -2127,7 +2127,7 @@ static struct eqos_ops eqos_stm32_ops = { .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32 }; -static const struct eqos_config eqos_stm32_config = { +static const struct eqos_config __maybe_unused eqos_stm32_config = { .reg_access_always_ok = false, .mdio_wait = 1, .swr_wait = 50, @@ -2154,7 +2154,7 @@ static struct eqos_ops eqos_imx_ops = { .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_imx }; -struct eqos_config eqos_imx_config = { +struct eqos_config __maybe_unused eqos_imx_config = { .reg_access_always_ok = false, .mdio_wait = 1, .swr_wait = 50, @@ -2165,18 +2165,24 @@ struct eqos_config eqos_imx_config = { }; static const struct udevice_id eqos_ids[] = { +#if IS_ENABLED(CONFIG_DWC_ETH_QOS_TEGRA186) { .compatible = "nvidia,tegra186-eqos", .data = (ulong)&eqos_tegra186_config }, +#endif +#if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32) { .compatible = "snps,dwmac-4.20a", .data = (ulong)&eqos_stm32_config }, +#endif +#if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX) { .compatible = "fsl,imx-eqos", .data = (ulong)&eqos_imx_config }, +#endif { } }; -- 2.17.1
RE: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional
Hi Marek, > From: Marek Vasut > Sent: mercredi 13 mai 2020 15:54 > > On 5/13/20 3:17 PM, Patrick DELAUNAY wrote: > > Hi David, > > > >> From: David Wu > >> Sent: mardi 12 mai 2020 11:56 > >> > >> For others using, clk_rx and clk_tx may not be necessary, and their > >> clock names are different. > >> > >> Signed-off-by: David Wu > >> --- > >> > >> Changes in v2: > >> - Don't change the Rx and Tx clock names. (Patrice, Stephen) > >> > >> drivers/net/dwc_eth_qos.c | 61 > >> +++ > >> 1 file changed, 29 insertions(+), 32 deletions(-) > >> [...] > > > > These clock are mandatory for STM32 glue as explain in Linux binding > > Documentation/devicetree/bindings/net/stm32-dwmac.txt > > > > But I fact when when I check the code, I see perhaps an issue in the > > current U- > Boot glue: > > we don't select the STM32 glue for the correct compatible, I think I > > will push > > > > static const struct udevice_id eqos_ids[] = { > > { > > .compatible = "nvidia,tegra186-eqos", > > .data = (ulong)&eqos_tegra186_config > > }, > > { > > - .compatible = "snps,dwmac-4.20a", > > + .compatible = "st,stm32mp1-dwmac", > > .data = (ulong)&eqos_stm32_config > > }, > > { > > .compatible = "fsl,imx-eqos", > > .data = (ulong)&eqos_imx_config > > }, > > > > { } > > }; > > > > Then you can manage your own glue for rockchip ETH for your compatible. > > You might even want to drop the tegra support on ARM32 , thus save space by > dropping useless code. For information I push 2 patches after this remark: [1] net: dwc_eth_qos: update the compatible supported for STM32 http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1-patrick.delau...@st.com/ [2] net: dwc_eth_qos: add Kconfig option to select supported configuration http://patchwork.ozlabs.org/project/uboot/list/?series=181931
RE: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB board to DM_ETH
>-Original Message- >From: U-Boot On Behalf Of Zhiqiang Hou >Sent: Friday, June 5, 2020 2:25 PM >To: u-boot@lists.denx.de; Priyanka Jain ; >bmeng...@gmail.com; olte...@gmail.com >Cc: Z.q. Hou >Subject: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB >board to DM_ETH > >From: Hou Zhiqiang > >Rebased this series on the top of master branch of https://gitlab.denx.de/u- >boot/custodians/u-boot-mpc85xx.git > I have requested a rebase on 'next' branch. I have pushed next branch to master (mpc85xx tree) as well today. So you can use that now Please rebase again. >This patch set depends on: >https://patchwork.ozlabs.org/project/uboot/list/?series=174343 > A patch for tsec migration to DM_MDIO was already submitted by Madalin which is now merged in mpc85xx tree. Let me know if that is fine or you need some additional patches from Vladimir. Regards Priyanka
Re: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional
On 6/8/20 11:29 AM, Patrick DELAUNAY wrote: [...] >>> we don't select the STM32 glue for the correct compatible, I think I >>> will push >>> >>> static const struct udevice_id eqos_ids[] = { >>> { >>> .compatible = "nvidia,tegra186-eqos", >>> .data = (ulong)&eqos_tegra186_config >>> }, >>> { >>> - .compatible = "snps,dwmac-4.20a", >>> + .compatible = "st,stm32mp1-dwmac", >>> .data = (ulong)&eqos_stm32_config >>> }, >>> { >>> .compatible = "fsl,imx-eqos", >>> .data = (ulong)&eqos_imx_config >>> }, >>> >>> { } >>> }; >>> >>> Then you can manage your own glue for rockchip ETH for your compatible. >> >> You might even want to drop the tegra support on ARM32 , thus save space by >> dropping useless code. > > For information I push 2 patches after this remark: > > [1] net: dwc_eth_qos: update the compatible supported for STM32 > > http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1-patrick.delau...@st.com/ > > [2] net: dwc_eth_qos: add Kconfig option to select supported configuration > http://patchwork.ozlabs.org/project/uboot/list/?series=181931 That's for -next, right ?
Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
On 6/8/20 11:07 AM, André Przywara wrote: > On 08/06/2020 09:02, Maxime Ripard wrote: >> Hi, >> >> On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote: >>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any >>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before >>> relocation. >>> >>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image >>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. >>> >>> CONFIG_LOG=Y is another setting requiring additional early malloc >>> area, cf. log_init(). >>> >>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled >>> we see as output in main U-Boot >>> >>> alloc_simple() alloc space exhausted >>> >>> With this patch the default values of SYS_MALLOC_F_LEN and >>> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. > > Heinrich, many thanks for the debugging and the nice solution! > >>> >>> Signed-off-by: Heinrich Schuchardt >> >> Where is this SYS_MALLOC_F_LEN allocated from (in particular for the >> SPL). Is it from the SRAM? > > This is the value for U-Boot proper only, so it's taken from DRAM. There > is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the > SPL is safe. SPL_SYS_MALLOC_F_LEN and TPL_SYS_MALLOC_F_LEN default to SYS_MALLOC_F_LEN. I am not aware of any TPL usage for ARCH_SUNXI. So this patch affects all three variables. But we should explicitly set the SPL_SYS_MALLOC_F_LEN default if 0x2000 is too big for any board. I will send a new version of the patch. Best regards Heinich > > Cheers, > Andre > >> >> If so, on older SoCs, we probably don't have 8k to spare. >> >> Maxime >> >
[PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any additional drivers marked as DM_FLAG_PRE_RELOC are loaded before relocation. CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. CONFIG_LOG=Y is another setting requiring additional early malloc area, cf. log_init(). When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled we see as output in main U-Boot alloc_simple() alloc space exhausted With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000. The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to 0x400 to avoid an increased usage of SRAM on elder SoCs. Signed-off-by: Heinrich Schuchardt --- v2 keep default for SPL_SYS_MALLOC_F_LEN at 0x400 --- Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 0e7ccc0b07..67b594cd74 100644 --- a/Kconfig +++ b/Kconfig @@ -146,7 +146,7 @@ config SYS_MALLOC_F_LEN default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \ ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \ ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \ - ARCH_LS1046A) + ARCH_LS1046A || ARCH_SUNXI) default 0x400 help Before relocation, memory is very limited on many platforms. Still, @@ -166,6 +166,7 @@ config SPL_SYS_MALLOC_F_LEN hex "Size of malloc() pool in SPL before relocation" depends on SYS_MALLOC_F && SPL default 0x2800 if RCAR_GEN3 + default 0x400 if ARCH_SUNXI default SYS_MALLOC_F_LEN help Before relocation, memory is very limited on many platforms. Still, -- 2.26.2
Re: rockchip: correctly set vop0 or vop1
On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote: > Patrick Wildt writes: > > Hi, > > > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or > > vop1, but so far we have set it in both conditions, which is not > > correct. > > > > Can someone verify this is the correct way round? vop1 -> set, > > vop0 -> clear? > > > > Signed-off-by: Patrick Wildt > > > > diff --git a/drivers/video/rockchip/rk_edp.c > > b/drivers/video/rockchip/rk_edp.c > > index 92188be9275..000bd481408 100644 > > --- a/drivers/video/rockchip/rk_edp.c > > +++ b/drivers/video/rockchip/rk_edp.c > > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev) > > rk_setreg(&priv->grf->soc_con12, 1 << 4); > > > > /* select epd signal from vop0 or vop1 */ > > - rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5)); > > + rk_clrsetreg(&priv->grf->soc_con6, (1 << 5), > > + (vop_id == 1) ? (1 << 5) : (0 << 5)); > > While working on PBP EDP support, found this too but I'm not sure it's > fine or not. For rk3399, my (not yet published) patch is doing: > > + if (vop_id == 0) > + rk_clrreg(&priv->grf->soc_con20, (1 << 5)); > + else > + rk_setreg(&priv->grf->soc_con20, (1 << 5)); > > I believe that the rk3288 may need similar treatment but I've yet to > look at the rk3288 manual. > > Arnaud Yes, it does. If you look at the linux code, they have: static const struct rockchip_dp_chip_data rk3399_edp = { .lcdsel_grf_reg = RK3399_GRF_SOC_CON20, .lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL), .lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, RK3399_EDP_LCDC_SEL), .chip_type = RK3399_EDP, }; static const struct rockchip_dp_chip_data rk3288_dp = { .lcdsel_grf_reg = RK3288_GRF_SOC_CON6, .lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL), .lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, RK3288_EDP_LCDC_SEL), .chip_type = RK3288_DP, }; which indicates that for rk3399 *and* rk3288 the bit has to be set to select "lit". Now your diff looks equivalent to mine, apart from using a different operation to achieve the same goal. The linux code does ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder); if (ret < 0) return; if (ret) val = dp->data->lcdsel_lit; else val = dp->data->lcdsel_big; Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit. That said, my diff seems to be fine, and your RK3399 code as well. Do you agree? Patrick
Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt wrote: > > The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any > additional drivers marked as DM_FLAG_PRE_RELOC are loaded before > relocation. > > CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image > verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. > > CONFIG_LOG=Y is another setting requiring additional early malloc > area, cf. log_init(). > > When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled > we see as output in main U-Boot > > alloc_simple() alloc space exhausted > > With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000. > The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to > 0x400 to avoid an increased usage of SRAM on elder SoCs. > > Signed-off-by: Heinrich Schuchardt > --- Reviewed-by: Jagan Teki
Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
On 08.06.20 13:50, Jagan Teki wrote: > On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt wrote: >> >> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any >> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before >> relocation. >> >> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image >> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. >> >> CONFIG_LOG=Y is another setting requiring additional early malloc >> area, cf. log_init(). >> >> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled >> we see as output in main U-Boot >> >> alloc_simple() alloc space exhausted >> >> With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000. >> The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to >> 0x400 to avoid an increased usage of SRAM on elder SoCs. >> >> Signed-off-by: Heinrich Schuchardt >> --- > > Reviewed-by: Jagan Teki > Thanks for reviewing. All sunxi boards have at least 32 KiB SRAM and only this 32 KiB used by U-Boot for SPL on all sunxi boards. A BananaPi with A20 CPU boots fine with SPL_SYS_MALLOC_F_LEN=0x2000. So it seems that also version 1 of the patch was on the safe side. Best regards Heinrich
Re: rockchip: correctly set vop0 or vop1
Patrick Wildt writes: > On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote: >> Patrick Wildt writes: >> >> Hi, >> >> > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or >> > vop1, but so far we have set it in both conditions, which is not >> > correct. >> > >> > Can someone verify this is the correct way round? vop1 -> set, >> > vop0 -> clear? >> > >> > Signed-off-by: Patrick Wildt >> > >> > diff --git a/drivers/video/rockchip/rk_edp.c >> > b/drivers/video/rockchip/rk_edp.c >> > index 92188be9275..000bd481408 100644 >> > --- a/drivers/video/rockchip/rk_edp.c >> > +++ b/drivers/video/rockchip/rk_edp.c >> > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev) >> >rk_setreg(&priv->grf->soc_con12, 1 << 4); >> > >> >/* select epd signal from vop0 or vop1 */ >> > - rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5)); >> > + rk_clrsetreg(&priv->grf->soc_con6, (1 << 5), >> > + (vop_id == 1) ? (1 << 5) : (0 << 5)); >> >> While working on PBP EDP support, found this too but I'm not sure it's >> fine or not. For rk3399, my (not yet published) patch is doing: >> >> + if (vop_id == 0) >> + rk_clrreg(&priv->grf->soc_con20, (1 << 5)); >> + else >> + rk_setreg(&priv->grf->soc_con20, (1 << 5)); >> >> I believe that the rk3288 may need similar treatment but I've yet to >> look at the rk3288 manual. >> >> Arnaud > > Yes, it does. If you look at the linux code, they have: > > static const struct rockchip_dp_chip_data rk3399_edp = { > .lcdsel_grf_reg = RK3399_GRF_SOC_CON20, > .lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL), > .lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, RK3399_EDP_LCDC_SEL), > .chip_type = RK3399_EDP, > }; > > static const struct rockchip_dp_chip_data rk3288_dp = { > .lcdsel_grf_reg = RK3288_GRF_SOC_CON6, > .lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL), > .lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, RK3288_EDP_LCDC_SEL), > .chip_type = RK3288_DP, > }; > > which indicates that for rk3399 *and* rk3288 the bit has to be set to > select "lit". Now your diff looks equivalent to mine, apart from using > a different operation to achieve the same goal. > > The linux code does > > ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder); > if (ret < 0) > return; > > if (ret) > val = dp->data->lcdsel_lit; > else > val = dp->data->lcdsel_big; > > Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this > would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit. > > That said, my diff seems to be fine, and your RK3399 code as well. Do > you agree? According to the code you've shown, it should be fine for rk3288 I guess but not for rk3399. Please note that it's grf soc_con6 register for rk3288 but grf soc_con20 for rk3399. Arnaud
Re: [RFC PATCH 1/1] gpio: Handle NULL pointers gracefully
On 01/06/20 11:08AM, Simon Glass wrote: > Hi Pratyush, > > On Fri, 29 May 2020 at 16:04, Pratyush Yadav wrote: > > > > Prepare the way for a managed GPIO API by handling NULL pointers without > > crashing or failing. validate_desc() comes from Linux with the prints > > removed to reduce code size. > > Please can you add a little detail as to why this is needed? Are you > trying to pass a NULL GPIO descriptor to the function? Copy-pasting from the cover letter: Patch [0] added devm_gpiod_get_index_optional() which would return NULL when when no GPIO was assigned to the requested function. This is convenient for drivers that need to handle optional GPIOs. We need to take a stance on who is responsible for the NULL check: the driver or the GPIO core? Do we want to trust drivers to take care of the NULL checks, or do we want to distrust them and make sure they don't send us anything bogus in the GPIO core. Linux does not generally trust drivers and usually verifies anything it gets from them. And FWIW, I see that the clk and phy subsystems in U-Boot also perform checks like this. The downside of the checks is of course that they increase code size. They might also slightly decrease performance. The benefit is that we don't burden drivers with taking care of this. The patch itself is based on a similar patch by Jean-Jacques. [0] https://patchwork.ozlabs.org/project/uboot/patch/20200529213808.2815-2-p.ya...@ti.com/ Maybe I should put this in the commit message? > > Signed-off-by: Jean-Jacques Hiblot > > Signed-off-by: Pratyush Yadav > > --- > > drivers/gpio/Kconfig | 9 > > drivers/gpio/gpio-uclass.c | 86 ++ > > include/asm-generic/gpio.h | 2 +- > > 3 files changed, 88 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > > index d87f6cc105..f8b6bcdf44 100644 > > --- a/drivers/gpio/Kconfig > > +++ b/drivers/gpio/Kconfig > > @@ -36,6 +36,15 @@ config TPL_DM_GPIO > > particular GPIOs that they provide. The uclass interface > > is defined in include/asm-generic/gpio.h. > > > > +config GPIO_VALIDATE_DESC > > + bool "Check if GPIO descriptor is NULL and bail out if it is" > > + depends on DM_GPIO > > + default y > > + help > > + If a GPIO is optional, the GPIO descriptor is NULL. In that > > + case, calls should bail out instead of causing NULL pointer > > + access. > > Can you update the gpio function docs in the header file with this info? Ok. > > + > > config GPIO_HOG > > bool "Enable GPIO hog support" > > depends on DM_GPIO > > diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c > > index 9eeab22eef..6b97d3aaff 100644 > > --- a/drivers/gpio/gpio-uclass.c > > +++ b/drivers/gpio/gpio-uclass.c > > @@ -20,6 +20,25 @@ > > > > DECLARE_GLOBAL_DATA_PTR; > > > > +#ifdef CONFIG_GPIO_VALIDATE_DESC > > +/* > > + * This descriptor validation needs to be inserted verbatim into each > > + * function taking a descriptor, so we need to use a preprocessor > > + * macro to avoid endless duplication. If the desc is NULL it is an > > + * optional GPIO and calls should just bail out. > > Is the macro defined elsewhere? It comes from the previous version of this patch. The macro has been removed in this version. Will fix. > > + */ > > +static inline int validate_desc(const struct gpio_desc *desc) > > +{ > > + if (!desc) > > + return 0; > > + if (IS_ERR(desc)) > > + return PTR_ERR(desc); > > + if (!desc->dev) > > + return -EINVAL; > > + return 1; > > +} > > #else > static inline int validate_desc(const struct gpio_desc *desc) > { > return 1; > } > > > +#endif > > + > > /** > > * gpio_desc_init() - Initialize the GPIO descriptor > > * > > @@ -303,11 +322,19 @@ int gpio_hog_lookup_name(const char *name, struct > > gpio_desc **desc) > > > > int dm_gpio_request(struct gpio_desc *desc, const char *label) > > { > > - struct udevice *dev = desc->dev; > > + struct udevice *dev; > > struct gpio_dev_priv *uc_priv; > > char *str; > > int ret; > > > > +#ifdef CONFIG_GPIO_VALIDATE_DESC > > Please drop the #ifdefs and use the static inline thing from above. Ok. > > + ret = validate_desc(desc); > > + if (ret <= 0) > > + return ret; > > Here you are returning 0 when you did not successfully request the > GPIO.You should return -ENOENT, otherwise callers have no idea what > happened and will get confused. Ok. To be clear, it is ok to return 0 in other places this check is done, right? > > +#endif > > + > > + dev = desc->dev; > > + > > uc_priv = dev_get_uclass_priv(dev); > > if (uc_priv->name[desc->offset]) > > return -EBUSY; > > @@ -434,6 +461,14 @@ static int check_reserved(const struct gpio_desc > > *desc, const c
Re: rockchip: correctly set vop0 or vop1
On Mon, Jun 08, 2020 at 02:24:32PM +0200, Arnaud Patard wrote: > Patrick Wildt writes: > > > On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote: > >> Patrick Wildt writes: > >> > >> Hi, > >> > >> > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or > >> > vop1, but so far we have set it in both conditions, which is not > >> > correct. > >> > > >> > Can someone verify this is the correct way round? vop1 -> set, > >> > vop0 -> clear? > >> > > >> > Signed-off-by: Patrick Wildt > >> > > >> > diff --git a/drivers/video/rockchip/rk_edp.c > >> > b/drivers/video/rockchip/rk_edp.c > >> > index 92188be9275..000bd481408 100644 > >> > --- a/drivers/video/rockchip/rk_edp.c > >> > +++ b/drivers/video/rockchip/rk_edp.c > >> > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev) > >> > rk_setreg(&priv->grf->soc_con12, 1 << 4); > >> > > >> > /* select epd signal from vop0 or vop1 */ > >> > -rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 > >> > << 5)); > >> > +rk_clrsetreg(&priv->grf->soc_con6, (1 << 5), > >> > +(vop_id == 1) ? (1 << 5) : (0 << 5)); > >> > >> While working on PBP EDP support, found this too but I'm not sure it's > >> fine or not. For rk3399, my (not yet published) patch is doing: > >> > >> + if (vop_id == 0) > >> + rk_clrreg(&priv->grf->soc_con20, (1 << 5)); > >> + else > >> + rk_setreg(&priv->grf->soc_con20, (1 << 5)); > >> > >> I believe that the rk3288 may need similar treatment but I've yet to > >> look at the rk3288 manual. > >> > >> Arnaud > > > > Yes, it does. If you look at the linux code, they have: > > > > static const struct rockchip_dp_chip_data rk3399_edp = { > > .lcdsel_grf_reg = RK3399_GRF_SOC_CON20, > > .lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL), > > .lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, > > RK3399_EDP_LCDC_SEL), > > .chip_type = RK3399_EDP, > > }; > > > > static const struct rockchip_dp_chip_data rk3288_dp = { > > .lcdsel_grf_reg = RK3288_GRF_SOC_CON6, > > .lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL), > > .lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, > > RK3288_EDP_LCDC_SEL), > > .chip_type = RK3288_DP, > > }; > > > > which indicates that for rk3399 *and* rk3288 the bit has to be set to > > select "lit". Now your diff looks equivalent to mine, apart from using > > a different operation to achieve the same goal. > > > > The linux code does > > > > ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder); > > if (ret < 0) > > return; > > > > if (ret) > > val = dp->data->lcdsel_lit; > > else > > val = dp->data->lcdsel_big; > > > > Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this > > would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit. > > > > That said, my diff seems to be fine, and your RK3399 code as well. Do > > you agree? > > According to the code you've shown, it should be fine for rk3288 I guess > but not for rk3399. Please note that it's grf soc_con6 register for rk3288 > but grf soc_con20 for rk3399. > > Arnaud Exactly, which is why you had that if defined() in your diff, to compile one part of the code for RK3288, and the other for RK3399. :) The bit though happens to be the same.
Re: Pull request for UEFI sub-system for efi-2020-07-rc4 (2)
On Sat, Jun 06, 2020 at 08:14:49AM +0200, Heinrich Schuchardt wrote: > The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140: > > configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-07-rc4-2 > > for you to fetch changes up to 325567d3c59fba32bdbf33a8ec981a8ccb096780: > > efi_loader: comments EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL (2020-06-05 > 04:04:41 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN
On Mon, Jun 8, 2020 at 8:25 AM Heinrich Schuchardt wrote: > > On 08.06.20 13:50, Jagan Teki wrote: > > On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt > > wrote: > >> > >> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any > >> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before > >> relocation. > >> > >> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image > >> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. > >> > >> CONFIG_LOG=Y is another setting requiring additional early malloc > >> area, cf. log_init(). > >> > >> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled > >> we see as output in main U-Boot > >> > >> alloc_simple() alloc space exhausted > >> > >> With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000. > >> The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to > >> 0x400 to avoid an increased usage of SRAM on elder SoCs. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > > > > Reviewed-by: Jagan Teki > > > > Thanks for reviewing. > > All sunxi boards have at least 32 KiB SRAM and only this 32 KiB used by > U-Boot for SPL on all sunxi boards. A BananaPi with A20 CPU boots fine > with SPL_SYS_MALLOC_F_LEN=0x2000. So it seems that also version 1 of the > patch was on the safe side. Okay. Planning to push this in MW, since the existing boards look fine. Jagan.
Re: [PATCH 1/7] Revert "mmc: zynq: parse dt when probing"
On 27. 05. 20 8:44, Jaehoon Chung wrote: > Hi > > On 5/22/20 7:44 PM, Michal Simek wrote: >> From: Ashok Reddy Soma >> >> This reverts commit 942b5fc03218d1c94468fc658e7dec65dabcc830. >> >> This is partial revert of the above commit. >> >> mmc_of_parse() is reading no-1-8-v from device tree and if set, >> it is clearing the UHS speed capabilities of cfg->host_caps. >> cfg->host_caps &= ~(UHS_CAPS | MMC_MODE_HS200 | >> MMC_MODE_HS400 | MMC_MODE_HS400_ES); >> >> This is still missing to clear UHS speeds like SDHCI_SUPPORT_SDR104, >> SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50. >> >> Even if we clear the flags SDHCI_SUPPORT_XXX in mmc_of_parse(), >> these speed flags are getting set again in cfg->host_caps in >> sdhci_setup_cfg(). >> >> The reason for this is, SDHCI_SUPPORT_XXX flags are cleared >> only if controller is not capable of supporting MMC_VDD_165_195 volts. >> >> if (caps & SDHCI_CAN_VDD_180) >> cfg->voltages |= MMC_VDD_165_195; >> >> if (!(cfg->voltages & MMC_VDD_165_195)) >> caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 | >> SDHCI_SUPPORT_DDR50); > > I don't have a target to test with zynq_sdhci. > If there is no effect no-1-8-v property, i think that it needs to fix main > problem. > I will check about this. Have you had any time to take a look at it? Thanks, Michal
Re: [PATCH 3/5] arm: qemu: implement enable_caches()
On Sat, Jun 06, 2020 at 10:50:59PM +0200, Heinrich Schuchardt wrote: > On 6/6/20 7:15 PM, Ard Biesheuvel wrote: > > Add an override for enable_caches to enable the I and D caches, along > > with the cached 1:1 mapping of all of DRAM. This is needed for running > > U-Boot under virtualization with QEMU/kvm. > > > > Signed-off-by: Ard Biesheuvel > > --- > > board/emulation/qemu-arm/qemu-arm.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/board/emulation/qemu-arm/qemu-arm.c > > b/board/emulation/qemu-arm/qemu-arm.c > > index 69e8ef46f1f5..1b0d543b93c1 100644 > > --- a/board/emulation/qemu-arm/qemu-arm.c > > +++ b/board/emulation/qemu-arm/qemu-arm.c > > @@ -4,6 +4,7 @@ > > */ > > > > #include > > +#include > > #include > > #include > > #include > > @@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void) > > return (void *)CONFIG_SYS_SDRAM_BASE; > > } > > > > +void enable_caches(void) > > +{ > > +icache_enable(); > > +dcache_enable(); > > +} > > + > > For other ARM architectures I have seen: > > int arch_cpu_init(void) > { > icache_enable(); > return 0; > } > > void enable_caches(void) > { > dcache_enable(); > } > > Some boards have > > if (!icache_status()) > icache_enable(); > > others > > #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF) > icache_enable(); > #endif > > Tom could you, please, advice what is the correct way to do it. Off-hand? Dealing with it per SoC/mach/board as we do today. Sometimes we need a dcache_disable() before the dcache_enable() as well to clear out previous mappings. So dropping this in here is probably the best choice for qemu-arm. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd
On Sun, Jun 7, 2020 at 7:22 PM Jagan Teki wrote: > > Some architecture like ARM Cortex A53, A72 would need > to invalidate dcache to sync the cache with the memory > contents before flushing the cache to memory. > > The NVME here submitting the admin command using dma_addr > to the memory without prior cache invalidation. This causing > dma_addr is pointing to an invalid location in the memory > and found the sane nvme_ctrl result. insane? > > Below example shows the nvme disk scan result improper result > > => nvme scan > nvme_get_info_from_identify: nn = 544502629, vwc = 100, > sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105 > > So, invalidating the cache before submitting the admin command > makes the dma_addr points to a valid location in the memory. > > Cc: Andre Przywara > Reported-by: Suniel Mahesh > Signed-off-by: Michael Trimarchi > Signed-off-by: Jagan Teki > Tested-by: Suniel Mahesh > --- > drivers/nvme/nvme.c | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Bin Meng
[PATCH 1/1] include/configs: ls1012a: Remove fdt_high env variable
From: Udit Agarwal Remove "fdt_high" environment variable to use the bootm_size to safely contain a kernel, device tree and initrd for relocation. Signed-off-by: Udit Agarwal --- include/configs/ls1012a2g5rdb.h | 2 +- include/configs/ls1012a_common.h | 2 +- include/configs/ls1012afrdm.h| 2 +- include/configs/ls1012afrwy.h| 2 +- include/configs/ls1012ardb.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/ls1012a2g5rdb.h b/include/configs/ls1012a2g5rdb.h index 869e0ad6b8..ad16fdcbd3 100644 --- a/include/configs/ls1012a2g5rdb.h +++ b/include/configs/ls1012a2g5rdb.h @@ -35,7 +35,6 @@ #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ "verify=no\0" \ - "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_addr=0x00f0\0" \ "kernel_addr=0x0100\0" \ @@ -49,6 +48,7 @@ "load_addr=0xa000\0"\ "kernel_size=0x280\0" \ "kernelheader_size=0x4\0" \ + "bootm_size=0x1000\0" \ "console=ttyS0,115200\0"\ BOOTENV \ "boot_scripts=ls1012ardb_boot.scr\0"\ diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h index 3bea9a9186..eed12e0234 100644 --- a/include/configs/ls1012a_common.h +++ b/include/configs/ls1012a_common.h @@ -83,11 +83,11 @@ "verify=no\0" \ "loadaddr=0x8010\0" \ "kernel_addr=0x10\0"\ - "fdt_high=0x\0" \ "initrd_high=0x\0" \ "kernel_start=0x100\0" \ "kernel_load=0xa000\0" \ "kernel_size=0x280\0" \ + "bootm_size=0x1000\0" \ #undef CONFIG_BOOTCOMMAND #ifdef CONFIG_TFABOOT diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h index 54ea43420f..dae06535d6 100644 --- a/include/configs/ls1012afrdm.h +++ b/include/configs/ls1012afrdm.h @@ -25,7 +25,6 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "verify=no\0" \ "fdt_high=0x\0" \ - "initrd_high=0x\0" \ "fdt_addr=0x00f0\0" \ "kernel_addr=0x0100\0" \ "scriptaddr=0x8000\0" \ @@ -35,6 +34,7 @@ "fdt_addr_r=0x9000\0" \ "load_addr=0x9600\0"\ "kernel_size=0x280\0" \ + "bootm_size=0x1000\0" \ "console=ttyS0,115200\0"\ BOOTENV \ "boot_scripts=ls1012afrdm_boot.scr\0" \ diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h index 1ea6548015..eeb1fa8122 100644 --- a/include/configs/ls1012afrwy.h +++ b/include/configs/ls1012afrwy.h @@ -46,7 +46,6 @@ #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ "verify=no\0" \ - "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_addr=0x00f0\0" \ "kernel_addr=0x0100\0" \ @@ -66,6 +65,7 @@ "load_addr=0x9200\0"\ "kernel_size=0x280\0" \ "kernelheader_size=0x4\0" \ + "bootm_size=0x1000\0" \ "console=ttyS0,115200\0"\ "BOARD=ls1012afrwy\0" \ BOOTENV \ diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index 8fb75650e2..428130ee57 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -54,7 +54,6 @@ #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ "verify=no\0" \ - "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_addr=0x00f0\0" \ "kernel_addr=0x0100\0" \ @@ -68,6 +67,7 @@ "load_addr=0xa000\0"\ "kernel_size=0x280\0" \ "kernelheader_size=0x4\0" \ + "bootm_size=0x1000\0" \ "console=ttyS0,115200\0"\ BOOTENV \ "boot_scripts=ls1012ardb_boot.scr\0"\ -- 2.17.1
Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd
On 07/06/2020 12:22, Jagan Teki wrote: Hi, (CC: ing Mark) Without looking to deep, I think invalidating the cache might be the right thing to do, but the rationale or at least the wording of it seems somehow flawed: > Some architecture like ARM Cortex A53, A72 would need Please don't mix the term "architecture" with actual implementations. And the problem is more general, I would say. This *might* be a case here where this is due to speculation, and then I would expect it to only show on an A72, for instance. I guess this is about NVMe on RK3399? Does U-Boot run on an A53 or an A72 core? > to invalidate dcache to sync the cache with the memory > contents before flushing the cache to memory. That is somewhat confusing. What does "sync" and "flush" mean here? AFAIK only "clean" and "invalidate" are clearly defined terms. The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is purely about the buffer for the *return* data, in which case I would expect this being a pure invalidation problem. This issue looks like the case described on slide 30 and 31 here: https://elinux.org/images/6/6d/Rutland2.pdf > The NVME here submitting the admin command using dma_addr > to the memory without prior cache invalidation. This causing > dma_addr is pointing to an invalid location in the memory This does not sound right: dma_addr is always pointing to the right location in memory. The actual reason this fixes something might be that (some) cache lines of the DMA buffer were dirty and were evicted *before* the existing invalidation, but *after* the DMA transfer. That sounds unlikely in an U-Boot context, though, but would match the case described in Mark's slides. So there might be more to this. Are we missing a barrier here? Should we use coherent buffers (memory mapped as un-cached) for the return DMA in the first place (but I don't think U-Boot provides those)? > and found the sane nvme_ctrl result. > > Below example shows the nvme disk scan result improper result > > => nvme scan > nvme_get_info_from_identify: nn = 544502629, vwc = 100, > sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105 > > So, invalidating the cache before submitting the admin command > makes the dma_addr points to a valid location in the memory. If this shows up already, I think we should address all the comments in the driver where it says we should do cache maintenance. And it makes me wonder how this actually works today ... Cheers, Andre. > > Cc: Andre Przywara > Reported-by: Suniel Mahesh > Signed-off-by: Michael Trimarchi > Signed-off-by: Jagan Teki > Tested-by: Suniel Mahesh > --- > drivers/nvme/nvme.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c > index 0357aba7f1..fc64d93ab8 100644 > --- a/drivers/nvme/nvme.c > +++ b/drivers/nvme/nvme.c > @@ -466,6 +466,9 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid, > > c.identify.cns = cpu_to_le32(cns); > > + invalidate_dcache_range(dma_addr, > + dma_addr + sizeof(struct nvme_id_ctrl)); > + > ret = nvme_submit_admin_cmd(dev, &c, NULL); > if (!ret) > invalidate_dcache_range(dma_addr, >
Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd
Hi On Mon, Jun 8, 2020 at 3:52 PM André Przywara wrote: > > On 07/06/2020 12:22, Jagan Teki wrote: > > Hi, > > (CC: ing Mark) > > Without looking to deep, I think invalidating the cache might be the > right thing to do, but the rationale or at least the wording of it seems > somehow flawed: > > > Some architecture like ARM Cortex A53, A72 would need > > Please don't mix the term "architecture" with actual implementations. > And the problem is more general, I would say. This *might* be a case > here where this is due to speculation, and then I would expect it to > only show on an A72, for instance. I guess this is about NVMe on RK3399? > Does U-Boot run on an A53 or an A72 core? > > > to invalidate dcache to sync the cache with the memory > > contents before flushing the cache to memory. > We will adjust commit message. The idea is that when we invalidate after the DMA transfer, a cache flush happen for the invalidation itself > That is somewhat confusing. What does "sync" and "flush" mean here? > AFAIK only "clean" and "invalidate" are clearly defined terms. > The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is > purely about the buffer for the *return* data, in which case I would > expect this being a pure invalidation problem. > Correct > This issue looks like the case described on slide 30 and 31 here: > https://elinux.org/images/6/6d/Rutland2.pdf > Thank you for point out to the slide > > The NVME here submitting the admin command using dma_addr > > to the memory without prior cache invalidation. This causing > > dma_addr is pointing to an invalid location in the memory > > This does not sound right: dma_addr is always pointing to the right > location in memory. > The actual reason this fixes something might be that (some) cache lines > of the DMA buffer were dirty and were evicted *before* the existing > invalidation, but *after* the DMA transfer. That sounds unlikely in an > U-Boot context, though, but would match the case described in Mark's slides. Does it not depend on how invalidation work in the particular CPU? > > So there might be more to this. Are we missing a barrier here? Should we > use coherent buffers (memory mapped as un-cached) for the return DMA in > the first place (but I don't think U-Boot provides those)? Right, I don't find a better way and yes this is general problem in uboot Michael > > > and found the sane nvme_ctrl result. > > > > Below example shows the nvme disk scan result improper result > > > > => nvme scan > > nvme_get_info_from_identify: nn = 544502629, vwc = 100, > > sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105 > > > > So, invalidating the cache before submitting the admin command > > makes the dma_addr points to a valid location in the memory. > > If this shows up already, I think we should address all the comments in > the driver where it says we should do cache maintenance. And it makes me > wonder how this actually works today ... > > Cheers, > Andre. > > > > > Cc: Andre Przywara > > Reported-by: Suniel Mahesh > > Signed-off-by: Michael Trimarchi > > Signed-off-by: Jagan Teki > > Tested-by: Suniel Mahesh > > --- > > drivers/nvme/nvme.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c > > index 0357aba7f1..fc64d93ab8 100644 > > --- a/drivers/nvme/nvme.c > > +++ b/drivers/nvme/nvme.c > > @@ -466,6 +466,9 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid, > > > > c.identify.cns = cpu_to_le32(cns); > > > > + invalidate_dcache_range(dma_addr, > > + dma_addr + sizeof(struct nvme_id_ctrl)); > > + > > ret = nvme_submit_admin_cmd(dev, &c, NULL); > > if (!ret) > > invalidate_dcache_range(dma_addr, > > > -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com |
[PATCH] rk3399: Add BOOTENV_SF command
Add missing BOOTENV_SF command in rk3399 config. Fix it. Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd") Signed-off-by: Jagan Teki Reported-by: Suniel Mahesh Tested-by: Suniel Mahesh --- include/configs/rk3399_common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h index f0ae6e67a7..e63ebb14f7 100644 --- a/include/configs/rk3399_common.h +++ b/include/configs/rk3399_common.h @@ -67,6 +67,7 @@ "partitions=" PARTS_DEFAULT \ ROCKCHIP_DEVICE_SETTINGS \ BOOTENV \ + BOOTENV_SF \ "altbootcmd=" \ "setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \ "run distro_bootcmd\0" -- 2.20.1
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Simon, On 4/6/20 12:59, Simon Glass wrote: Hi Walter, On Fri, 29 May 2020 at 12:15, Walter Lozano wrote: Currently dtoc scans dtbs to convert them to struct platdata and to generate U_BOOT_DEVICE entries. These entries need to be filled with the driver name, but at this moment the information used is the compatible name present in the dtb. This causes that only nodes with a compatible name that matches a driver name generate a working entry. In order to improve this behaviour, this patch adds to dtoc the capability of scan drivers source code to generate a list of valid driver names. This allows to rise a warning in the case that an U_BOOT_DEVICE entry will try to use a name not valid. Additionally, in order to add more flexibility to the solution, adds the U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an easy way to declare driver name aliases. Thanks to this, dtoc can look for the driver name based on its alias when it populates the U_BOOT_DEVICE entry. Signed-off-by: Walter Lozano --- include/dm/device.h| 7 tools/dtoc/dtb_platdata.py | 83 -- 2 files changed, 86 insertions(+), 4 deletions(-) diff --git a/include/dm/device.h b/include/dm/device.h index 975eec5d0e..2cfe10766f 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -282,6 +282,13 @@ struct driver { #define DM_GET_DRIVER(__name) \ ll_entry_get(struct driver, __name, driver) +/** + * Declare a macro to state a alias for a driver name. This macro will + * produce no code but its information will be parsed by tools like + * dtoc + */ +#define U_BOOT_DRIVER_ALIAS(__name, __alias) + /** * dev_get_platdata() - Get the platform data for a device * diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py index ecfe0624d1..23cfda2f88 100644 --- a/tools/dtoc/dtb_platdata.py +++ b/tools/dtoc/dtb_platdata.py @@ -13,6 +13,8 @@ static data. import collections import copy +import os +import re import sys from dtoc import fdt @@ -140,6 +142,9 @@ class DtbPlatdata(object): _include_disabled: true to include nodes marked status = "disabled" _outfile: The current output file (sys.stdout or a real file) _lines: Stashed list of output lines for outputting in the future +_aliases: Dict that hold aliases for compatible strings key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx) ?? value: ... Noted. +_drivers: List of valid driver names found in drivers/ +_driver_aliases: Dict that holds aliases for driver names key: vaue: OK. """ def __init__(self, dtb_fname, include_disabled): self._fdt = None @@ -149,6 +154,35 @@ class DtbPlatdata(object): self._outfile = None self._lines = [] self._aliases = {} +self._drivers = [] +self._driver_aliases = {} + +def get_normalized_compat_name(self, node): +"""Get a node's normalized compat name + +Returns a valid driver name by retrieving node's first compatible +string as a C identifier and perfomrming a check against _drivers performing Noted. +and a lookup in driver_aliases rising a warning in case of failure. s/ rising/, printing/ OK. + +Args: +node: Node object to check +Return: +Tuple: +Driver name associated with the first compatible string +List of C identifiers for all the other compatible strings +(possibly empty) Can you update this comment to explain what is returned when it is not found? Sure. +""" +compat_c, aliases_c = get_compat_name(node) +if compat_c not in self._drivers: +compat_c_old = compat_c +compat_c = self._driver_aliases.get(compat_c) +if not compat_c: +print('WARNING: the driver %s was not found in the driver list' % (compat_c_old)) This creates lots of warnings at present. Either we need a patch to clean up the differences in the source code, or we need to disable the warning. Regarding this, maybe we should have a list of driver names we don't expect to support, like simple_bus. For this to work probably the best approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS, so each config can add their owns. Also the warning is not really actionable. It needs to add mention of U_BOOT_DEVICE and ...ALIAS. I agree with you. Thanks. In future we can scan the compatible strings and tell the user what changes to make, I suppose. Yes, it will be a great improvement! +compat_c = compat_c_old +else: # pragma: no cover Need to fix the coverage here Noted. I will a few more tests. +aliases_c = [compat_c_old] + aliases_c + +return compat_c, aliases_c def setup_output(self, fname):
Re: [PATCH 02/10] dtoc: add option to disable warnings
Hi Simon, On 4/6/20 12:59, Simon Glass wrote: Hi Walter, On Fri, 29 May 2020 at 12:15, Walter Lozano wrote: As dtoc now performs checks for valid driver names, when running dtoc tests several warnings arise as these tests don't use valid driver names. This patch adds an option to disable those warning, which is only intended for running tests. Signed-off-by: Walter Lozano --- tools/dtoc/dtb_platdata.py | 11 +--- tools/dtoc/test_dtoc.py| 54 +++--- 2 files changed, 34 insertions(+), 31 deletions(-) diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py index 23cfda2f88..0a54188348 100644 --- a/tools/dtoc/dtb_platdata.py +++ b/tools/dtoc/dtb_platdata.py @@ -141,17 +141,19 @@ class DtbPlatdata(object): _valid_nodes: A list of Node object with compatible strings _include_disabled: true to include nodes marked status = "disabled" _outfile: The current output file (sys.stdout or a real file) +_warning_disabled: true to disable warnings about driver names not found _lines: Stashed list of output lines for outputting in the future _aliases: Dict that hold aliases for compatible strings _drivers: List of valid driver names found in drivers/ _driver_aliases: Dict that holds aliases for driver names """ -def __init__(self, dtb_fname, include_disabled): +def __init__(self, dtb_fname, include_disabled, warning_disable): self._fdt = None self._dtb_fname = dtb_fname self._valid_nodes = None self._include_disabled = include_disabled self._outfile = None +self._warning_disable = warning_disable self._lines = [] self._aliases = {} self._drivers = [] @@ -177,7 +179,8 @@ class DtbPlatdata(object): compat_c_old = compat_c compat_c = self._driver_aliases.get(compat_c) if not compat_c: -print('WARNING: the driver %s was not found in the driver list' % (compat_c_old)) +if not self._warning_disable: # pragma: no cover Need coverage for this. No problem! +print('WARNING: the driver %s was not found in the driver list' % (compat_c_old)) compat_c = compat_c_old else: # pragma: no cover aliases_c = [compat_c_old] + aliases_c @@ -623,7 +626,7 @@ class DtbPlatdata(object): nodes_to_output.remove(node) -def run_steps(args, dtb_file, include_disabled, output): +def run_steps(args, dtb_file, include_disabled, output, warning_disable = False): no spaces around = Sure. """Run all the steps of the dtoc tool Args: @@ -635,7 +638,7 @@ def run_steps(args, dtb_file, include_disabled, output): if not args: raise ValueError('Please specify a command: struct, platdata') -plat = DtbPlatdata(dtb_file, include_disabled) +plat = DtbPlatdata(dtb_file, include_disabled, warning_disable) plat.scan_drivers() plat.scan_dtb() plat.scan_tree() diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py index 8498e8303c..a9b605cac8 100755 --- a/tools/dtoc/test_dtoc.py +++ b/tools/dtoc/test_dtoc.py @@ -154,12 +154,12 @@ class TestDtoc(unittest.TestCase): """Test output from a device tree file with no nodes""" dtb_file = get_dtb_file('dtoc_test_empty.dts') output = tools.GetOutputFilename('output') -dtb_platdata.run_steps(['struct'], dtb_file, False, output) +dtb_platdata.run_steps(['struct'], dtb_file, False, output, True) with open(output) as infile: lines = infile.read().splitlines() self.assertEqual(HEADER.splitlines(), lines) -dtb_platdata.run_steps(['platdata'], dtb_file, False, output) +dtb_platdata.run_steps(['platdata'], dtb_file, False, output, True) Can you create run_test which calls run_steps with that set that to True, to avoid adding the param everywhere in this file? Sure, no problem. Thanks! Regards, Walter
Re: [PATCH 05/10] core: extend struct driver_info to point to device
On 4/6/20 12:59, Simon Glass wrote: Hi Walter, On Fri, 29 May 2020 at 12:15, Walter Lozano wrote: Currently when creating an U_BOOT_DEVICE entry a struct driver_info is declared, which contains the data needed to instantiate the device. However, the actual device is created at runtime and there is no proper way to get the device based on its struct driver_info. This patch extends struct driver_info adding a pointer to udevice which is populated during the bind process, allowing to generate a set of functions to get the device based on its struct driver_info. Signed-off-by: Walter Lozano --- drivers/core/device.c | 26 +++--- drivers/core/root.c | 4 include/dm/device.h | 14 ++ include/dm/platdata.h | 14 ++ 4 files changed, 55 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass Nits below Thanks for taking the time! diff --git a/drivers/core/device.c b/drivers/core/device.c index a0ad080aaf..5adbc30849 100644 --- a/drivers/core/device.c +++ b/drivers/core/device.c @@ -250,6 +250,7 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only, { struct driver *drv; uint platdata_size = 0; + int ret = 0; Can you drop = 0 ? Noted! drv = lists_driver_lookup_name(info->name); if (!drv) @@ -260,9 +261,16 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only, #if CONFIG_IS_ENABLED(OF_PLATDATA) platdata_size = info->platdata_size; #endif - return device_bind_common(parent, drv, info->name, - (void *)info->platdata, 0, ofnode_null(), platdata_size, - devp); + ret = device_bind_common(parent, drv, info->name, +(void *)info->platdata, 0, ofnode_null(), +platdata_size, devp); + if (ret) + return ret; +#if CONFIG_IS_ENABLED(OF_PLATDATA) + info->dev = *devp; +#endif + + return ret; } static void *alloc_priv(int size, uint flags) @@ -727,6 +735,18 @@ int device_get_global_by_ofnode(ofnode ofnode, struct udevice **devp) return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp); } +#if CONFIG_IS_ENABLED(OF_PLATDATA) +int device_get_by_driver_info(const struct driver_info *info, + struct udevice **devp) +{ + struct udevice *dev; + + dev = info->dev; + + return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp); +} +#endif + int device_find_first_child(const struct udevice *parent, struct udevice **devp) { if (list_empty(&parent->child_head)) { diff --git a/drivers/core/root.c b/drivers/core/root.c index c9ee56478a..8f47a6b356 100644 --- a/drivers/core/root.c +++ b/drivers/core/root.c @@ -346,6 +346,10 @@ int dm_init_and_scan(bool pre_reloc_only) { int ret; +#if CONFIG_IS_ENABLED(OF_PLATDATA) + populate_phandle_data(); +#endif + ret = dm_init(IS_ENABLED(CONFIG_OF_LIVE)); if (ret) { debug("dm_init() failed: %d\n", ret); diff --git a/include/dm/device.h b/include/dm/device.h index 2cfe10766f..a3b3e5bc46 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -538,6 +538,20 @@ int device_find_global_by_ofnode(ofnode node, struct udevice **devp); */ int device_get_global_by_ofnode(ofnode node, struct udevice **devp); +/** + * device_get_by_driver_info() - Get a device based on driver_info + * + * Locates a device by its struct driver_info. + * + * The device is probed to activate it ready for use. + * + * @info: Struct driver_info Here you should mention using DM_GET_DRIVER() to find it. OK, I'll add a reference. + * @devp: Returns pointer to device if found, otherwise this is set to NULL + * @return 0 if OK, -ve on error + */ +int device_get_by_driver_info(const struct driver_info *info, + struct udevice **devp); + /** * device_find_first_child() - Find the first child of a device * diff --git a/include/dm/platdata.h b/include/dm/platdata.h index c972fa6936..238379b0e4 100644 --- a/include/dm/platdata.h +++ b/include/dm/platdata.h @@ -22,12 +22,14 @@ * @name: Driver name * @platdata: Driver-specific platform data * @platdata_size: Size of platform data structure + * @dev: Device created from this structure data */ struct driver_info { const char *name; const void *platdata; #if CONFIG_IS_ENABLED(OF_PLATDATA) uint platdata_size; + struct udevice *dev; #endif }; @@ -43,4 +45,16 @@ struct driver_info { #define U_BOOT_DEVICES(__name) \ ll_entry_declare_list(struct driver_info, __name, driver_info) +/* Get a pointer to a given driver */ +#define DM_GET_DEVICE(__name) \ + ll_entry_get(struct driver_info, __name, driver_info) + +/** + * populate_phandle_data() - Populates ph
Re: [PATCH 07/10] dm: doc: update of-plat with new phandle support
Hi Simon, On 4/6/20 12:59, Simon Glass wrote: On Fri, 29 May 2020 at 12:15, Walter Lozano wrote: Update documentation to reflect the new phandle support when OF_PLATDATA is used. Now phandles are implemented as pointers to U_BOOT_DEVICE, which makes it possible to get a pointer to the actual device. Signed-off-by: Walter Lozano --- doc/driver-model/of-plat.rst | 24 1 file changed, 16 insertions(+), 8 deletions(-) Reviewed-by: Simon Glass But note dm_populate_... I would like it to be easy to see what module/subsystem a function belongs to. Sure, I totally agree. Thanks again for your deep review. Regards, Walter
Re: [PATCH 09/10] dtoc: update dtb_platdata to support cd-gpios
Hi Simon On 4/6/20 12:59, Simon Glass wrote: On Fri, 29 May 2020 at 12:15, Walter Lozano wrote: Currently dtoc does not support the property cd-gpios used to declare the gpios for card detect in mmc. This patch adds support to cd-gpios property. Signed-off-by: Walter Lozano --- tools/dtoc/dtb_platdata.py | 13 - tools/dtoc/test_dtoc.py| 2 +- 2 files changed, 9 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass But I think you should mention GPIOs, rather than just cd-gpios, as it seems this will add support for any GPIO. Sorry, probably I am missing something, but in order to support GPIOs in general we need to support a set of properties such as "cs-gpios", "rb-gpios", "gpios" among others. Do you agree? Regards, Walter
[PATCH 1/1] log: uclass_get_name() depends on CONFIG_SPL_DM
If CONFIG_SPL_DM=n and CONFIG_SPL_LOG=y a build error occurs: ld.bfd: common/built-in.o: in function `log_get_cat_name': common/log.c:48: undefined reference to `uclass_get_name' make[1]: *** [scripts/Makefile.spl:422: spl/u-boot-spl] Error 1 Call uclass_get_name() only if DM is enabled. Signed-off-by: Heinrich Schuchardt --- common/log.c | 4 1 file changed, 4 insertions(+) diff --git a/common/log.c b/common/log.c index c5b9b489ca..d7ce74f6b3 100644 --- a/common/log.c +++ b/common/log.c @@ -45,7 +45,11 @@ const char *log_get_cat_name(enum log_category_t cat) if (cat >= LOGC_NONE) return log_cat_name[cat - LOGC_NONE]; +#if CONFIG_IS_ENABLED(DM) name = uclass_get_name((enum uclass_id)cat); +#else + name = NULL; +#endif return name ? name : ""; } -- 2.26.2
Re: [PATCH] test_sleep.py: make sleep time and margin configurable
On 6/4/20 9:24 AM, Heiko Schocher wrote: > make the sleep time and the margin configurable. Reviewed-by: Stephen Warren
Re: [PATCH] test_sleep.py: make sleep time and margin configurable
On 6/7/20 7:45 AM, Simon Glass wrote: > On Thu, 4 Jun 2020 at 09:24, Heiko Schocher wrote: >> >> make the sleep time and the margin configurable. >> >> Signed-off-by: Heiko Schocher >> --- >> >> travis build: >> https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225 >> >> This patch is needed as I start test/py now within tbot [1]. On >> some configurations U-Boot is compiled on a build machine for >> example in munich, while the board under test is in my lab in >> hungary. >> >> So the 0.25 seconds default margin is often to low because >> of latencies on the net. >> >> See as an example configuration (within tbot): >> >> https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29 >> >> [1] http://tbot.tools/modules/tc.html#u-boot-test-py >> >> test/py/tests/test_sleep.py | 14 +++--- >> 1 file changed, 11 insertions(+), 3 deletions(-) > > Reviewed-by: Simon Glass > > Related, at some point we should change sandbox to fake the time > movement since this test currently waits for three seconds even on > sandbox. We definitely shouldn't do that; that's the exact kind of failure this test is intended to detect.
Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc
Hi Simon, On Thu, Jun 4, 2020 at 8:30 AM Simon Glass wrote: > > Hi Rayagonda, > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur > wrote: > > > > Hi Simon, > > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass wrote: > > > > > > Hi Rayagonda, > > > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur > > > wrote: > > > > > > > > Hi Thomas, > > > > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons > > > > wrote: > > > > > > > > > > Rayagonda Kokatanur writes: > > > > > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini > > > > > > wrote: > > > > > >> > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur > > > > > >> wrote: > > > > > >> > Hi Tom, > > > > > >> > > > > > > >> > > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini > > > > > >> > wrote: > > > > > >> > > > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur > > > > > >> > > wrote: > > > > > >> > > > > > > > >> > > > This is the second patch set series prepared on top of the > > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc"). > > > > > >> > > > > > > > > >> > > > This patch set will add following, > > > > > >> > > > -dt nodes and defconfig options for basic device like > > > > > >> > > > pinctrl, > > > > > >> > > > gpio, mmc, qspi, wdt, i2c and pcie. > > > > > >> > > > -start wdt service > > > > > >> > > > -Enable GPT commands > > > > > >> > > > -Enable EXT4 and FAT fs support > > > > > >> > > > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come > > > > > >> > > from > > > > > >> > > mainline Linux or at least linux-next and have had some level > > > > > >> > > upstream > > > > > >> > > review, right? Thanks! > > > > > >> > > > > > > >> > Yes. All the DTS changes are merged in the Linux and are > > > > > >> > available at > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/ > > > > > >> > > > > > >> Great. Please reference the release you're taking these from as > > > > > >> that > > > > > >> will make future resyncs easier. Thanks! > > > > > > > > > > > > It's Linux v5.6. > > > > > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts? I > > > > > looked at the mainline Linux device trees and I couldn't easily see > > > > > the > > > > > correspondence. Will the renaming complicate synchronization? > > > > > > > > Do we need to maintain the same dt file between linux and uboot ? > > > > Also in uboot we don't enable all devices, how do we handle this ? > > > > > > If there is no U-Boot driver for a particular node then it will be > > > ignored. It is easier to keep them in sync if they are the same in > > > U-Boot and Linux. > > > > > > > Please let me know. > > > > > > That is implied by your question above :-) > > > > NS3 board is derivative of the existing bcm95874t board > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt) > > Hence we have different dt for NS3 in Linux but it is not yet upstremed. > > > > I compared the dt file size between uboot and Linux. > > Uboot dt size = 9K > > Linux dt size = 41K (32K extra) > > > > In uboot we have 8MB non-volatile SPI flash memory. > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB > > space is allocated to other components > > like nitor/bnxt firmware image, DDR shmoo value and for backup image. > > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this > > will use extra 33K memory of allocated 1.5MB. > > This increase in 33K will reduce total memory availability for u-boot > > and other features (like ARM trusted firmware, Op-TEE OS) development > > in future. > > Hence we anticipate qpsi memory shortage going ahead for new features. > > > > So please let me know your view on maintaining different dt files in uboot. > > Sounds like you have plenty of memory, actually. Is U-Boot the first > thing to load? > > I think it is important to use the same filename and have the same DT > contents where they are present in U-Boot. But if you want to leave > out nodes, etc., that seems OK to me. It should be easy enough to meld > in the updates later. > > I wonder if we should add a way to drop unused nodes for U-Boot > proper, like we do for SPL? Thank you for your suggestion. Right now linux dt files are not upstremed. Upstreaming linux dt files first and then using the same in uboot will delay these uboot patch merge. Hence I am planning to do following, 1. Use one sample dt file with just few basic nodes so that uboot can be built without any issues. 2. Parallely start linux dt file upstream. 3. Once the linux dt file gets merged, I will pull them into uboot and submit a patch. Please let me know. Best regards, Rayagonda > > Regards, > Simon
Re: [PATCH] Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"
On 6/8/20 2:24 AM, Michal Simek wrote: > It is in u-boot mainline from February. Then we had to fix it in April. Do you have a link/commit hash for said fix? > In the middle of this I have seen IIC one patchset which improves hex > handling which is likely better way then this. Same for this. > I am fine with reverting this patch but I would also like to see more > comments in the code to say that we shouldn't really change this. This seems like a larger issue. There is a lot of code in U-Boot implementing the C standard library, especially the string library. Should we have a comment in each file which says something like "The functions here implement the C standard, think carefully before making semantic changes"? --Sean
RE: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional
Dear Marek, > From: Marek Vasut > Sent: lundi 8 juin 2020 11:45 > > On 6/8/20 11:29 AM, Patrick DELAUNAY wrote: > [...] > >>> we don't select the STM32 glue for the correct compatible, I think I > >>> will push > >>> > >>> static const struct udevice_id eqos_ids[] = { > >>> { > >>> .compatible = "nvidia,tegra186-eqos", > >>> .data = (ulong)&eqos_tegra186_config > >>> }, > >>> { > >>> - .compatible = "snps,dwmac-4.20a", > >>> + .compatible = "st,stm32mp1-dwmac", > >>> .data = (ulong)&eqos_stm32_config > >>> }, > >>> { > >>> .compatible = "fsl,imx-eqos", > >>> .data = (ulong)&eqos_imx_config > >>> }, > >>> > >>> { } > >>> }; > >>> > >>> Then you can manage your own glue for rockchip ETH for your compatible. > >> > >> You might even want to drop the tegra support on ARM32 , thus save > >> space by dropping useless code. > > > > For information I push 2 patches after this remark: > > > > [1] net: dwc_eth_qos: update the compatible supported for STM32 > > > > http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1 > > -patrick.delau...@st.com/ > > > > [2] net: dwc_eth_qos: add Kconfig option to select supported configuration > > http://patchwork.ozlabs.org/project/uboot/list/?series=181931 > > That's for -next, right ? Yes both are for -next. It is driver improvement (=code size reduction and cleanup compatible) and no bugfix. Patrick.
Re: [PATCH] Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"
Hi, On Mon, 8 Jun 2020 at 00:24, Michal Simek wrote: > > On 07. 06. 20 7:36, Sean Anderson wrote: > > This reverts commit 0486497e2b5f4d36fa968a1a60fea358cbf70b65. > > > > The strtoul has well-defined semantics. It is defined by the C standard and > > POSIX. To quote the relevant section of the man pages, > > > >> If base is zero or 16, the string may then include a "0x" prefix, and the > >> number will be read in base 16; otherwise, a zero base is taken as 10 > >> (decimal) unless the next character is '0', in which case it is taken as > >> 8 (octal). > > > > Keeping these semantics is important for several reasons. First, it is very > > surprising for standard library functions to behave differently than usual. > > Every other implementation of strtoul has different semantics than the > > implementation in U-Boot at the moment. Second, it can result in very > > surprising results from small changes. For example, changing the string > > "1f" to "20" causes the parsed value to *decrease*. Forcing use of the "0x" > > prefix to specify hexidecimal numbers is a feature, not a bug. Lastly, this > > is slightly less performant, since the entire number is parsed twice. > > > > This fixes the str_simple_strtoul test failing with > > > > test/str_ut.c:29, run_strtoul(): expect_val == val: Expected 0x44b (1099), > > got 0x1099ab (1087915) > > test/str_ut.c:46, str_simple_strtoul(): 0 == run_strtoul(uts, str2, 0, > > 1099, 4): Expected 0x0 (0), got 0x1 (1) > > > > Signed-off-by: Sean Anderson > > CC: Michal Simek > > CC: Shiril Tichkule > > --- > > > > lib/strto.c | 18 +- > > 1 file changed, 1 insertion(+), 17 deletions(-) > > > > diff --git a/lib/strto.c b/lib/strto.c > > index 3d77115d4d..c00bb5895d 100644 > > --- a/lib/strto.c > > +++ b/lib/strto.c > > @@ -22,25 +22,9 @@ static const char *_parse_integer_fixup_radix(const char > > *s, unsigned int *base) > > *base = 16; > > else > > *base = 8; > > - } else { > > - int i = 0; > > - char var; > > - > > + } else > > *base = 10; > > - > > - do { > > - var = tolower(s[i++]); > > - if (var >= 'a' && var <= 'f') { > > - *base = 16; > > - break; > > - } > > - > > - if (!(var >= '0' && var <= '9')) > > - break; > > - } while (var); > > - } > > } > > - > > if (*base == 16 && s[0] == '0' && tolower(s[1]) == 'x') > > s += 2; > > return s; > > > > > It is in u-boot mainline from February. Then we had to fix it in April. > In the middle of this I have seen IIC one patchset which improves hex > handling which is likely better way then this. > I am fine with reverting this patch but I would also like to see more > comments in the code to say that we shouldn't really change this. Once this revert is in I think we should refrain from changing it until there are tests to cover its current behaviour, e.g. in str_ut.c Reviewed-by: Simon Glass Regards, Simon
Re: [PATCH 1/1] log: uclass_get_name() depends on CONFIG_SPL_DM
Hi Heinrich, On Mon, 8 Jun 2020 at 10:04, Heinrich Schuchardt wrote: > > If CONFIG_SPL_DM=n and CONFIG_SPL_LOG=y a build error occurs: > > ld.bfd: common/built-in.o: in function `log_get_cat_name': > common/log.c:48: undefined reference to `uclass_get_name' > make[1]: *** [scripts/Makefile.spl:422: spl/u-boot-spl] Error 1 > > Call uclass_get_name() only if DM is enabled. > > Signed-off-by: Heinrich Schuchardt > --- > common/log.c | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH] test_sleep.py: make sleep time and margin configurable
Hi Stephen, On Mon, 8 Jun 2020 at 10:43, Stephen Warren wrote: > > On 6/7/20 7:45 AM, Simon Glass wrote: > > On Thu, 4 Jun 2020 at 09:24, Heiko Schocher wrote: > >> > >> make the sleep time and the margin configurable. > >> > >> Signed-off-by: Heiko Schocher > >> --- > >> > >> travis build: > >> https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225 > >> > >> This patch is needed as I start test/py now within tbot [1]. On > >> some configurations U-Boot is compiled on a build machine for > >> example in munich, while the board under test is in my lab in > >> hungary. > >> > >> So the 0.25 seconds default margin is often to low because > >> of latencies on the net. > >> > >> See as an example configuration (within tbot): > >> > >> https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29 > >> > >> [1] http://tbot.tools/modules/tc.html#u-boot-test-py > >> > >> test/py/tests/test_sleep.py | 14 +++--- > >> 1 file changed, 11 insertions(+), 3 deletions(-) > > > > Reviewed-by: Simon Glass > > > > Related, at some point we should change sandbox to fake the time > > movement since this test currently waits for three seconds even on > > sandbox. > > We definitely shouldn't do that; that's the exact kind of failure this > test is intended to detect. No, we're not looking for bugs in sandbox's time handling. We are just testing the plumbing associated with delaying (timer driver, etc.). Regards, Simon
Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc
Hi Rayagonda, On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur wrote: > > Hi Simon, > > On Thu, Jun 4, 2020 at 8:30 AM Simon Glass wrote: > > > > Hi Rayagonda, > > > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur > > wrote: > > > > > > Hi Simon, > > > > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass wrote: > > > > > > > > Hi Rayagonda, > > > > > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur > > > > wrote: > > > > > > > > > > Hi Thomas, > > > > > > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons > > > > > wrote: > > > > > > > > > > > > Rayagonda Kokatanur writes: > > > > > > > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini > > > > > > > wrote: > > > > > > >> > > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur > > > > > > >> wrote: > > > > > > >> > Hi Tom, > > > > > > >> > > > > > > > >> > > > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini > > > > > > >> > wrote: > > > > > > >> > > > > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda > > > > > > >> > > Kokatanur wrote: > > > > > > >> > > > > > > > > >> > > > This is the second patch set series prepared on top of the > > > > > > >> > > > first patch set ("add initial support for broadcom NS3 > > > > > > >> > > > soc"). > > > > > > >> > > > > > > > > > >> > > > This patch set will add following, > > > > > > >> > > > -dt nodes and defconfig options for basic device like > > > > > > >> > > > pinctrl, > > > > > > >> > > > gpio, mmc, qspi, wdt, i2c and pcie. > > > > > > >> > > > -start wdt service > > > > > > >> > > > -Enable GPT commands > > > > > > >> > > > -Enable EXT4 and FAT fs support > > > > > > >> > > > > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either > > > > > > >> > > come from > > > > > > >> > > mainline Linux or at least linux-next and have had some > > > > > > >> > > level upstream > > > > > > >> > > review, right? Thanks! > > > > > > >> > > > > > > > >> > Yes. All the DTS changes are merged in the Linux and are > > > > > > >> > available at > > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/ > > > > > > >> > > > > > > >> Great. Please reference the release you're taking these from as > > > > > > >> that > > > > > > >> will make future resyncs easier. Thanks! > > > > > > > > > > > > > > It's Linux v5.6. > > > > > > > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts? I > > > > > > looked at the mainline Linux device trees and I couldn't easily see > > > > > > the > > > > > > correspondence. Will the renaming complicate synchronization? > > > > > > > > > > Do we need to maintain the same dt file between linux and uboot ? > > > > > Also in uboot we don't enable all devices, how do we handle this ? > > > > > > > > If there is no U-Boot driver for a particular node then it will be > > > > ignored. It is easier to keep them in sync if they are the same in > > > > U-Boot and Linux. > > > > > > > > > Please let me know. > > > > > > > > That is implied by your question above :-) > > > > > > NS3 board is derivative of the existing bcm95874t board > > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt) > > > Hence we have different dt for NS3 in Linux but it is not yet upstremed. > > > > > > I compared the dt file size between uboot and Linux. > > > Uboot dt size = 9K > > > Linux dt size = 41K (32K extra) > > > > > > In uboot we have 8MB non-volatile SPI flash memory. > > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB > > > space is allocated to other components > > > like nitor/bnxt firmware image, DDR shmoo value and for backup image. > > > > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this > > > will use extra 33K memory of allocated 1.5MB. > > > This increase in 33K will reduce total memory availability for u-boot > > > and other features (like ARM trusted firmware, Op-TEE OS) development > > > in future. > > > Hence we anticipate qpsi memory shortage going ahead for new features. > > > > > > So please let me know your view on maintaining different dt files in > > > uboot. > > > > Sounds like you have plenty of memory, actually. Is U-Boot the first > > thing to load? > > > > I think it is important to use the same filename and have the same DT > > contents where they are present in U-Boot. But if you want to leave > > out nodes, etc., that seems OK to me. It should be easy enough to meld > > in the updates later. > > > > I wonder if we should add a way to drop unused nodes for U-Boot > > proper, like we do for SPL? > > Thank you for your suggestion. > > Right now linux dt files are not upstremed. > Upstreaming linux dt files first and then using the same in uboot will U-Boot > delay these uboot patch merge. > Hence I am planning to do following, > 1. Use one sample dt file with just few basic nodes so that uboot can > be built without any issues. > 2. Parallely start linux dt file upstream. > 3. Once the linux dt file gets merged, I will
Re: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional
On 6/8/20 7:05 PM, Patrick DELAUNAY wrote: > Dear Marek, Hi, >> From: Marek Vasut >> Sent: lundi 8 juin 2020 11:45 >> >> On 6/8/20 11:29 AM, Patrick DELAUNAY wrote: >> [...] > we don't select the STM32 glue for the correct compatible, I think I > will push > > static const struct udevice_id eqos_ids[] = { > { > .compatible = "nvidia,tegra186-eqos", > .data = (ulong)&eqos_tegra186_config > }, > { > - .compatible = "snps,dwmac-4.20a", > + .compatible = "st,stm32mp1-dwmac", > .data = (ulong)&eqos_stm32_config > }, > { > .compatible = "fsl,imx-eqos", > .data = (ulong)&eqos_imx_config > }, > > { } > }; > > Then you can manage your own glue for rockchip ETH for your compatible. You might even want to drop the tegra support on ARM32 , thus save space by dropping useless code. >>> >>> For information I push 2 patches after this remark: >>> >>> [1] net: dwc_eth_qos: update the compatible supported for STM32 >>> >>> http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1 >>> -patrick.delau...@st.com/ >>> >>> [2] net: dwc_eth_qos: add Kconfig option to select supported configuration >>> http://patchwork.ozlabs.org/project/uboot/list/?series=181931 >> >> That's for -next, right ? > > Yes both are for -next. > > It is driver improvement (=code size reduction and cleanup compatible) and no > bugfix. I am still not entirely sure whether the ifdeffery is the way to go. I wonder whether we can't rather somehow use the linker-lists to generate a list of compatible strings at runtime (like we do for commands) and then reduce that list to only the compatible strings present in the DT (that's a bit tricky).
Re: [PATCH] riscv: sbi: Add newline to error message
On Sat, Jun 6, 2020 at 12:26 PM Sean Anderson wrote: > > Signed-off-by: Sean Anderson > > --- > > common/spl/spl_opensbi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c > index e88136e6f3..14f335f75f 100644 > --- a/common/spl/spl_opensbi.c > +++ b/common/spl/spl_opensbi.c > @@ -56,7 +56,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image) > /* Find U-Boot image in /fit-images */ > ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, &uboot_node); > if (ret) { > - pr_err("Can't find U-Boot node, %d", ret); > + pr_err("Can't find U-Boot node, %d\n", ret); > hang(); > } > > -- > 2.26.2 > Reviewed-by: Atish Patra -- Regards, Atish
[PATCH 5/5] verdin-imx8mm: Select the watchdog driver
> Currently watchdog driver is not selected, which causes system to reboot > after staying 60s in the U-Boot prompt. > Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be > properly serviced. > Signed-off-by: Fabio Estevam > Acked-by: Igor Opaniuk Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] power: pmic: Add SPL Kconfig entry for PFUZE100
> Add Kconfig entry for the PFUZE PMIC, SPL variant. > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Jaehoon Chung > Cc: Peng Fan > Cc: Stefano Babic > Reviewed-by: Jaehoon Chung Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v3 3/5] imx8mp_evk: spl: use spl_early_init
> From: Peng Fan > Use spl_early_init to replace spl_init, spl_init will be invoked > in board_init_r, we only need use spl_early_init to setup malloc > and scan early dt. > Signed-off-by: Peng Fan > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v2 1/1] imx: rom api: fix image offset computation
> When not booting from FlexSPI, the offset computation is: > offset = image_offset + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - > 0x8000; > When booting from SD card or eMMC user partition, image_offset is > 0x8000. It is useless to add and remove 0x8000. > When booting from other device, image_offset is 0 so this computation is > wrong. > Simplfy this computation to work on all booting devices. > Signed-off-by: Sébastien Szymanski Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] ARM: dts: imxrt1050: indent lcdif node correctly
> Accidentally submitted a patch with indentation not correct, let's fix it > by indenting wrong lines. > Signed-off-by: Giulio Benetti > Acked-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] imx: Update MTD partitions layout for display5 (i.MX6Q) board
> This change updates the MTD partition layout on SPI-NOR memory for display5 > board. > Signed-off-by: Lukasz Majewski Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH 2/2] ARM: dts: imx: m53menlo: Convert to DM_ETH
> Convert the board to DM_ETH instead of legacy networking. This requires > a minor addition to the DT to satisfy the requirement for specifying a > PHY node. No functional change from board user perspective. > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: NXP i.MX U-Boot Team > Cc: Peng Fan > Cc: Stefano Babic Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v3 1/5] imx8mp_evk: spl: drop useless code
> From: Peng Fan > Drop useless getting ccm device, there is no need to explicted do this > in board code, and we not enable SPL CLK currently. > Signed-off-by: Peng Fan > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v3 4/5] imx8mp_evk: spl: no need the code since spl framework could do that
> From: Peng Fan > We no need invoke the code, since spl framework could help > us do that. > Signed-off-by: Peng Fan > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
imx: move ATF to the back of the FIT to fix loading over yModem
> With yModem the FIT Image is only supplied once, so we can only > seek forward in the yModem supplied image and never backwards. > With the recent changes to the SPL mechanism, including loading > U-Boot first, FDT after, then the loadables, we must also reorder > the FIT image script to make sure that the loadables are last in > the FIT image. > Signed-off-by: Patrick Wildt > Tested-by: Sébastien Szymanski > diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh > b/arch/arm/mach-imx/mkimage_fit_atf.sh > index dd1ca5ad3fd..fe12b7bb4bd 100755 > --- a/arch/arm/mach-imx/mkimage_fit_atf.sh > +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh > @@ -62,6 +62,23 @@ cat << __HEADER_EOF > compression = "none"; > load = <$BL33_LOAD_ADDR>; > }; > +__HEADER_EOF > + > +cnt=1 > +for dtname in $* > +do > + cat << __FDT_IMAGE_EOF > + fdt@$cnt { > + description = "$(basename $dtname .dtb)"; > + data = /incbin/("$dtname"); > + type = "flat_dt"; > + compression = "none"; > + }; > +__FDT_IMAGE_EOF > +cnt=$((cnt+1)) > +done > + > +cat << __HEADER_EOF > atf@1 { > description = "ARM Trusted Firmware"; > os = "arm-trusted-firmware"; > @@ -88,20 +105,6 @@ cat << __HEADER_EOF > __HEADER_EOF > fi > > -cnt=1 > -for dtname in $* > -do > - cat << __FDT_IMAGE_EOF > - fdt@$cnt { > - description = "$(basename $dtname .dtb)"; > - data = /incbin/("$dtname"); > - type = "flat_dt"; > - compression = "none"; > - }; > -__FDT_IMAGE_EOF > -cnt=$((cnt+1)) > -done > - > cat << __CONF_HEADER_EOF > }; > configurations { Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] imx8mp_evk: Add a README file
> Add a README file explaining the U-Boot build and SD card flash procedures. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH 2/5] imx8mn_ddr4_evk: Select the watchdog driver
> Currently watchdog driver is not selected, which causes system to reboot > after staying 60s in the U-Boot prompt. > Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be > properly serviced. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc
On Mon, Jun 8, 2020 at 10:43 PM Simon Glass wrote: > > Hi Rayagonda, > > On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur > wrote: > > > > Hi Simon, > > > > On Thu, Jun 4, 2020 at 8:30 AM Simon Glass wrote: > > > > > > Hi Rayagonda, > > > > > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass wrote: > > > > > > > > > > Hi Rayagonda, > > > > > > > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur > > > > > wrote: > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons > > > > > > wrote: > > > > > > > > > > > > > > Rayagonda Kokatanur writes: > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini > > > > > > > > wrote: > > > > > > > >> > > > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur > > > > > > > >> wrote: > > > > > > > >> > Hi Tom, > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini > > > > > > > >> > wrote: > > > > > > > >> > > > > > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda > > > > > > > >> > > Kokatanur wrote: > > > > > > > >> > > > > > > > > > >> > > > This is the second patch set series prepared on top of > > > > > > > >> > > > the > > > > > > > >> > > > first patch set ("add initial support for broadcom NS3 > > > > > > > >> > > > soc"). > > > > > > > >> > > > > > > > > > > >> > > > This patch set will add following, > > > > > > > >> > > > -dt nodes and defconfig options for basic device like > > > > > > > >> > > > pinctrl, > > > > > > > >> > > > gpio, mmc, qspi, wdt, i2c and pcie. > > > > > > > >> > > > -start wdt service > > > > > > > >> > > > -Enable GPT commands > > > > > > > >> > > > -Enable EXT4 and FAT fs support > > > > > > > >> > > > > > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either > > > > > > > >> > > come from > > > > > > > >> > > mainline Linux or at least linux-next and have had some > > > > > > > >> > > level upstream > > > > > > > >> > > review, right? Thanks! > > > > > > > >> > > > > > > > > >> > Yes. All the DTS changes are merged in the Linux and are > > > > > > > >> > available at > > > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/ > > > > > > > >> > > > > > > > >> Great. Please reference the release you're taking these from > > > > > > > >> as that > > > > > > > >> will make future resyncs easier. Thanks! > > > > > > > > > > > > > > > > It's Linux v5.6. > > > > > > > > > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts? > > > > > > > I > > > > > > > looked at the mainline Linux device trees and I couldn't easily > > > > > > > see the > > > > > > > correspondence. Will the renaming complicate synchronization? > > > > > > > > > > > > Do we need to maintain the same dt file between linux and uboot ? > > > > > > Also in uboot we don't enable all devices, how do we handle this ? > > > > > > > > > > If there is no U-Boot driver for a particular node then it will be > > > > > ignored. It is easier to keep them in sync if they are the same in > > > > > U-Boot and Linux. > > > > > > > > > > > Please let me know. > > > > > > > > > > That is implied by your question above :-) > > > > > > > > NS3 board is derivative of the existing bcm95874t board > > > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt) > > > > Hence we have different dt for NS3 in Linux but it is not yet upstremed. > > > > > > > > I compared the dt file size between uboot and Linux. > > > > Uboot dt size = 9K > > > > Linux dt size = 41K (32K extra) > > > > > > > > In uboot we have 8MB non-volatile SPI flash memory. > > > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB > > > > space is allocated to other components > > > > like nitor/bnxt firmware image, DDR shmoo value and for backup image. > > > > > > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this > > > > will use extra 33K memory of allocated 1.5MB. > > > > This increase in 33K will reduce total memory availability for u-boot > > > > and other features (like ARM trusted firmware, Op-TEE OS) development > > > > in future. > > > > Hence we anticipate qpsi memory shortage going ahead for new features. > > > > > > > > So please let me know your view on maintaining different dt files in > > > > uboot. > > > > > > Sounds like you have plenty of memory, actually. Is U-Boot the first > > > thing to load? > > > > > > I think it is important to use the same filename and have the same DT > > > contents where they are present in U-Boot. But if you want to leave > > > out nodes, etc., that seems OK to me. It should be easy enough to meld > > > in the updates later. > > > > > > I wonder if we should add a way to drop unused nodes for U-Boot > > > proper, like we do for SPL? > > > > Thank you for your suggestion. > > > > Right now linux dt files are not upstremed. > > Ups
[PATCH 4/5] imx8mp_evk: Select the watchdog driver
> Currently watchdog driver is not selected, which causes system to reboot > after staying 60s in the U-Boot prompt. > Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be > properly serviced. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v3 2/5] imx8mp_evk: spl: drop timer_init
> From: Peng Fan > timer_init has been invoked in arch_cpu_init, no need to invoke > it again in board code. > Signed-off-by: Peng Fan > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH v3 5/5] imx: imx8mp_evk: fix boot issue
> From: Peng Fan > The u-boot-spl.bin pad with ddr firmware conflicts with the > CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten > by malloc in SPL stage and cause ddr initialization not able > to finish. So update the related addresses to fix the issue. > Reported-by: Fabio Estevam > Signed-off-by: Peng Fan > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] imx: Kconfig: enable IMX_BOOTAUX for i.MX8M
> i.MX8M could use imx bootaux to boot m4/m7 core, so let's add it > to the dependency list. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH 3/5] imx8mm_beacon: Select the watchdog driver
> Currently watchdog driver is not selected, which causes system to reboot > after staying 60s in the U-Boot prompt. > Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be > properly serviced. > Signed-off-by: Fabio Estevam > Reviewed-by: Adam Ford Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH 1/2] ARM: imx: m53menlo: Do not fail boot on invalid splash screen
> None of these splash screen loading errors are so critical as to > justify complete failure to boot, so just print error message as > needed and return 0, the boot can very likely continue without > the splash. > Fix a couple of missing free(dst) instances as well. > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: NXP i.MX U-Boot Team > Cc: Peng Fan > Cc: Stefano Babic Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH] ARM: imx: ddr: Add missing PHY reset
> The iMX7D RM 9.2.4.9.3 Power removal flow Table 9-11. Re-enabling power > explicitly says both the DDR controller and the PHY must be reset in the > correct sequence. Currently the code only resets the controller. This > leads to a misbehavior where the system brings the DRAM up after reboot, > but the DRAM is unstable. Add the missing reset. > The easiest way to trigger this is by triggering WDT without having the > WDT assert WDOG_B signal, i.e. mw.w 0x3028 0x25 . > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: NXP i.MX U-Boot Team > Cc: Peng Fan > Cc: Stefano Babic Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
[PATCH 1/5] imx8mm_evk: Select the watchdog driver
> Currently the watchdog driver is not selected, which causes the following > warnings in both SPL and U-Boot proper: > U-Boot SPL 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300) > Normal Boot > WDT: Started without servicing (60s timeout) > Trying to boot from MMC1 > U-Boot 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300) > CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz > Reset cause: POR > Model: FSL i.MX8MM EVK board > DRAM: 2 GiB > WDT: Started without servicing (60s timeout) > > System reboots after staying 60s in the U-Boot prompt. > Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be > properly serviced. > Suggested-by: Marek Vasut > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 =
Re: [PATCH] test_sleep.py: make sleep time and margin configurable
On 6/8/20 11:12 AM, Simon Glass wrote: > Hi Stephen, > > On Mon, 8 Jun 2020 at 10:43, Stephen Warren wrote: >> >> On 6/7/20 7:45 AM, Simon Glass wrote: >>> On Thu, 4 Jun 2020 at 09:24, Heiko Schocher wrote: make the sleep time and the margin configurable. Signed-off-by: Heiko Schocher --- travis build: https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225 This patch is needed as I start test/py now within tbot [1]. On some configurations U-Boot is compiled on a build machine for example in munich, while the board under test is in my lab in hungary. So the 0.25 seconds default margin is often to low because of latencies on the net. See as an example configuration (within tbot): https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29 [1] http://tbot.tools/modules/tc.html#u-boot-test-py test/py/tests/test_sleep.py | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) >>> >>> Reviewed-by: Simon Glass >>> >>> Related, at some point we should change sandbox to fake the time >>> movement since this test currently waits for three seconds even on >>> sandbox. >> >> We definitely shouldn't do that; that's the exact kind of failure this >> test is intended to detect. > > No, we're not looking for bugs in sandbox's time handling. We are just > testing the plumbing associated with delaying (timer driver, etc.). The entire purpose of the test is to look for bugs in the backend implementation of the time handling. I should know; I wrote the test!
Re: [PATCH v2 0/2] gpio: Add a managed API
Hi Simon, On 01/06/20 08:45AM, Simon Glass wrote: > Hi Pratyush, > > On Mon, 1 Jun 2020 at 05:22, Pratyush Yadav wrote: > > > > On 31/05/20 08:08AM, Simon Glass wrote: > > > Hi Pratyush, > > > > > > On Fri, 29 May 2020 at 15:39, Pratyush Yadav wrote: > > > > > > > > Hi, > > > > > > > > This is a re-submission of Jean-Jacques' earlier work in October last > > > > year. It can be found at [0]. The goal is to facilitate porting drivers > > > > from the linux kernel. Most of the series will be about adding managed > > > > API to existing infrastructure (GPIO, reset, regmap (already > > > > submitted)). > > > > > > > > This particular series is about GPIOs. It adds a managed API using the > > > > API as Linux. To make it 100% compatible with linux, there is a small > > > > deviation from u-boot's way of naming the gpio lists: the managed > > > > equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is > > > > devm_gpiod_get_index(..., "blabla", ...) > > > > > > > > Changes in v2: > > > > - The original series had a patch that checked for NULL pointers in the > > > > core GPIO functions. The checks were needed because of the addition of > > > > devm_gpiod_get_index_optional() which would return NULL when when no > > > > GPIO was assigned to the requested function. This is convenient for > > > > drivers that need to handle optional GPIOs. > > > > > > > > Simon argued that those should be behind a Kconfig option because of > > > > code size concerns. He also argued against implicit return in the > > > > macro that checked for the optional GPIOs. > > > > > > > > This submission removes the controversial patch so that base > > > > functionality can get unblocked. > > > > > > > > We still need to take a stance on who is responsible for the NULL > > > > check: the driver or the GPIO core? Do we want to trust drivers to > > > > take care of the NULL checks, or do we want to distrust them and make > > > > sure they don't send us anything bogus in the GPIO core. For now the > > > > responsibility lies on the drivers by default. I will send a separate > > > > RFC of the NULL check patch and we can probably discuss the issue > > > > there. > > > > > > > > [0] > > > > https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhib...@ti.com/ > > > > > > > > Jean-Jacques Hiblot (2): > > > > drivers: gpio: Add a managed API to get a GPIO from the device-tree > > > > test: gpio: Add tests for the managed API > > > > > > > > arch/sandbox/dts/test.dts | 10 > > > > drivers/gpio/gpio-uclass.c | 70 + > > > > include/asm-generic/gpio.h | 47 + > > > > test/dm/gpio.c | 102 + > > > > 4 files changed, 229 insertions(+) > > > > > > > > -- > > > > 2.26.2 > > > > > > > > > > The first question I have is why do you want to allocate the gpio_desc > > > and return it? Doesn't the caller have a place for that in its private > > > struct? > > > > Ask the Linux folks that ;-) > > > > The main aim of this series is to make it easier to port and maintain > > drivers from Linux. The less changes we have to make when porting a > > driver, the easier it is to port future fixes and features. > > > > Linux drivers (like the TI J721E WIZ [0] for which this effort is mainly > > being made) use these APIs. FWIW, the docs in Linux say the optional > > wrappers to the functions are added as a convenience for drivers that > > need to handle optional GPIOs. > > U-Boot already supports optional GPIOs. I seem to have mixed up some things when sending the reply. Sorry. This patchset doesn't really have all that much to do with optional GPIOs. It is about adding managed counterparts to the GPIO APIs. > Can we put this behind a CONFIG_LINUX_COMPAT_GPIO flag perhaps, so > people know they are trading off code / memory size for compatibility? The decision to put these behind a config depends on what U-Boot's stance is on the "devm_*" functions in general. I see that there are devm_clk_*() functions in mainline already and they aren't beind a Kconfig option. A quick search tells me as of now no other subsystem has devm_* functions in mainline, though you did drop your Reviewed-by on the regmap patch that adds devm_regmap_init() [0] and it isn't guarded by a Kconfig option. So as of now I see the stance is to add devm_* functions without wrapping them in a compile time switch. If we don't want to make building them mandatory (at the added cognitive cost of code that harder to reason about because of the multiple ways you can build it), that can be done but IMO we should be consistent about what we put behind a config. One note I have about devm_gpiod_get_index() (which is the main source of new code) is that I don't think it is possible to have a dummy function in its stead since it is not a direct call to a lower level function and instead it plays around with the propname suffix. So i
[PATCH v4 0/4] rockchip: rk3399: Add SPI boot
Now, nvme scan seems stable with environment. This series v4 version for SPI boot support on rk3399. Changes for v4: - adjust env offset, size changes for v3: - SPI env offset, size changes based on roc-rk3399-pc Changes for v2: - same defconfig to support both MMC, SPI boot - add spi flash program document Any inputs? Jagan. Jagan Teki (4): Makefile: Drop to handle rkspi image type roc-rk3399-pc: Mark default env from SPI roc-rk3399-pc: Add SPI boot doc: rockchip: Document SPI flash program steps Makefile | 11 ++ arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 ++- configs/roc-pc-mezzanine-rk3399_defconfig | 7 +- configs/roc-pc-rk3399_defconfig | 7 +- doc/board/rockchip/rockchip.rst | 26 ++- include/configs/roc-pc-rk3399.h | 4 6 files changed, 50 insertions(+), 17 deletions(-) -- 2.20.1
[PATCH v4 2/4] roc-rk3399-pc: Mark default env from SPI
Mark the default U-Boot environment as SPI flash since this is an on board flash device. Updated env offset, size in contrast with default since the U-Boot proper has starting from 384K. Signed-off-by: Jagan Teki --- Changes for v4: - adjust env offset, size configs/roc-pc-mezzanine-rk3399_defconfig | 4 +++- configs/roc-pc-rk3399_defconfig | 4 +++- include/configs/roc-pc-rk3399.h | 4 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 1c1539bcb9..9c6fd0c98c 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -1,7 +1,9 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_ROC_PC_RK3399=y CONFIG_NR_DRAM_BANKS=1 @@ -25,7 +27,7 @@ CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc-mezzanine" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index 76e76c160e..b225eb38fe 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -1,7 +1,9 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_ROC_PC_RK3399=y CONFIG_NR_DRAM_BANKS=1 @@ -24,7 +26,7 @@ CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y diff --git a/include/configs/roc-pc-rk3399.h b/include/configs/roc-pc-rk3399.h index d4cbc3532e..59fe22289c 100644 --- a/include/configs/roc-pc-rk3399.h +++ b/include/configs/roc-pc-rk3399.h @@ -13,10 +13,6 @@ #include -#if defined(CONFIG_ENV_IS_IN_MMC) -# define CONFIG_SYS_MMC_ENV_DEV0 -#endif - #define SDRAM_BANK_SIZE(2UL << 30) #endif -- 2.20.1
[PATCH v4 1/4] Makefile: Drop to handle rkspi image type
On rockchip platforms, SPI boot image creation is not straightforward like MMC boot image creation where former requires to specify tpl, spl in multimage format in mkimage, and later simply do a concatenate mkimaged-tpl with spl. On this note, let drop rkspi image type creation via kbuild and let inform via rockchip.rst Reviewed-by: Kever Yang Signed-off-by: Jagan Teki --- Changes for v4: - none Makefile | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 3851dd9fa0..db3b6b9991 100644 --- a/Makefile +++ b/Makefile @@ -1438,22 +1438,15 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE ifeq ($(CONFIG_ARCH_ROCKCHIP),y) -# rockchip image type -ifeq ($(CONFIG_SPL_SPI_LOAD),y) -ROCKCHIP_IMG_TYPE := rkspi -else -ROCKCHIP_IMG_TYPE := rksd -endif - # TPL + SPL ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy) -MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE $(call if_changed,mkimage) idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE $(call if_changed,cat) else -MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd idbloader.img: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) endif -- 2.20.1
[PATCH v4 3/4] roc-rk3399-pc: Add SPI boot
U-Boot TPL 2020.07-rc3-00090-gd4e919f927-dirty (Jun 01 2020 - 23:45:53) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530) Trying to boot from MMC1 NOTICE: BL31: v2.2(release): NOTICE: BL31: Built : 15:05:37, May 12 2020 U-Boot 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530) SoC: Rockchip rk3399 Reset cause: POR Model: Firefly ROC-RK3399-PC Board DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe32: 1, sdhci@fe33: 0 Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Model: Firefly ROC-RK3399-PC Board Reviewed-by: Kever Yang Signed-off-by: Jagan Teki --- Changes for v4: - none arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 +++- configs/roc-pc-mezzanine-rk3399_defconfig | 3 +++ configs/roc-pc-rk3399_defconfig | 3 +++ 3 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi index 141dd0b306..fc155e6903 100644 --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi @@ -12,7 +12,11 @@ }; chosen { - u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc; + u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc; + }; + + config { + u-boot,spl-payload-offset = <0x6>; /* @ 384KB */ }; vcc_hub_en: vcc_hub_en-regulator { @@ -40,6 +44,12 @@ vin-supply = <&vcc_vbus_typec0>; }; +&spi1 { + spi_flash: flash@0 { + u-boot,dm-pre-reloc; + }; +}; + &vdd_log { regulator-min-microvolt = <43>; regulator-init-microvolt = <95>; diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 9c6fd0c98c..03ba519af1 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -9,12 +9,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y CONFIG_TPL_GPIO_SUPPORT=y CONFIG_CMD_BOOTZ=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index b225eb38fe..b59b54bd89 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -9,12 +9,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y CONFIG_TPL_GPIO_SUPPORT=y CONFIG_CMD_BOOTZ=y -- 2.20.1
[PATCH v4 4/4] doc: rockchip: Document SPI flash program steps
Document SPI flash program steps for rockchip platforms. Suggested-by: Hugh Cole-Baker Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- Changes for v4: - none doc/board/rockchip/rockchip.rst | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index 7b72fab496..76b228a046 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -162,6 +162,30 @@ Program the flash:: Note: for rockchip 32-bit platforms the U-Boot proper image is u-boot-dtb.img +SPI +^^^ + +Generating idbloader for SPI boot would require to input a multi image +image format to mkimage tool instead of concerting (like for MMC boot). + +SPL-alone SPI boot image:: + +./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img + +TPL+SPL SPI boot image:: + +./tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img + +Copy SPI boot images into SD card and boot from SD:: + +sf probe +load mmc 1:1 $kernel_addr_r idbloader.img +sf erase 0 +$filesize +sf write $kernel_addr_r 0 ${filesize} +load mmc 1:1 ${kernel_addr_r} u-boot.itb +sf erase 0x6 +$filesize +sf write $kernel_addr_r 0x6 ${filesize} + TODO @@ -171,4 +195,4 @@ TODO - Add missing SoC's with it boards list .. Jagan Teki -.. Sunday 24 May 2020 10:08:41 PM IST +.. Tuesday 02 June 2020 12:18:57 AM IST -- 2.20.1
[PATCH v3 0/5] roc-rk3399-pc: Custom SPL init
This series supports custom initialization code required for roc-rk3399-pc board on SPL stage. I have marked it as v3, since we have tried this before on this series[1]. Now this series is well mature code handling to add custom spl_board_init code parts. roc-rk3399-pc would require custom leds initialization based on user intervention of the power key. This code handles the user intervention via SPI environment variable. If someone or production systems wants this feature then 'pwr_key' has to be set otherwise it is normal like other rk3399 boards in Mainline. Changes for v3: - support leds on SPL - support env 'pwr_key' [1] https://patchwork.ozlabs.org/project/uboot/patch/20200319101251.7354-1-ja...@amarulasolutions.com/ Any inputs? Jagan. Jagan Teki (5): rk3399: spl: Add rk_spl_board_init as __weak rk3399: spl: Print SPL banner after relocation roc-rk3399-pc: Move leds setup in SPL rockchip: Separate the reset cause from display cpuinfo roc-rk3399-pc: Set LED only during POR and pwr_key=y arch/arm/include/asm/arch-rockchip/cru.h| 2 + arch/arm/mach-rockchip/Makefile | 5 +- arch/arm/mach-rockchip/cpu-info.c | 20 +--- arch/arm/mach-rockchip/rk3399/rk3399.c | 11 +++- arch/arm/mach-rockchip/spl.c| 1 - arch/arm/mach-rockchip/tpl.c| 7 --- board/firefly/roc-pc-rk3399/Makefile| 4 ++ board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 21 board/firefly/roc-pc-rk3399/spl.c | 56 + configs/roc-pc-mezzanine-rk3399_defconfig | 6 ++- configs/roc-pc-rk3399_defconfig | 6 ++- 11 files changed, 96 insertions(+), 43 deletions(-) create mode 100644 board/firefly/roc-pc-rk3399/spl.c -- 2.20.1
[PATCH v3 1/5] rk3399: spl: Add rk_spl_board_init as __weak
Current spl_board_init is mostly specific to puma-rk3399 target and in other words it cannot be required or useful for other rk3399 boards. Some boards require their custom initialization to be part of spl_board_init like roc-rk3399-pc require leds setup, environments. So, this patch handles all these possible scenarios. Add rk_spl_board_init as __weak so that boards that require their own custom initialization can be defined on their board file. Signed-off-by: Jagan Teki Tested-by: Suniel Mahesh --- Changes for v3: - new patch arch/arm/mach-rockchip/rk3399/rk3399.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 4fda93b152..681f80f339 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -241,7 +241,7 @@ static void rk3399_force_power_on_reset(void) } #endif -void spl_board_init(void) +__weak void rk_spl_board_init(void) { #if defined(SPL_GPIO_SUPPORT) struct rockchip_cru *cru = rockchip_get_cru(); @@ -274,4 +274,11 @@ void spl_board_init(void) debug("%s: Cannot enable boot on regulator\n", __func__); #endif } + +void spl_board_init(void) +{ + /* board specific spl init */ + rk_spl_board_init(); +} + #endif -- 2.20.1
[PATCH v3 2/5] rk3399: spl: Print SPL banner after relocation
Usually printing the SPL banner varies between architecture or board codes. - Some would print before relocation at the end board_init_f for making sure all initialization prior to this would happen properly. if at all there is a requirement for serial init, that happens properly since it prints all after that. - Some would print after relocation at the spl_board_init for making sure all initialization prior to relocation would happen properly. Also debug uart on these cases would be available before relocation. So debug support is available in before and after relocation. Rockchip SPL is following formar step to print the banner at the end of board_init_f. To support various custom use cases in SPL like leds, environment, board detections later options like printing the banner after relocation would be a better option. Printing banner would also help to support debugging availability between relocation codes, like debug uart available before relocation and banner availability after relation. By demonstrating all the above use cases, this patch is trying to print the SPL banner after relocation. Signed-off-by: Jagan Teki Tested-by: Suniel Mahesh --- Changes for v3: - new patch arch/arm/mach-rockchip/rk3399/rk3399.c | 2 ++ arch/arm/mach-rockchip/spl.c | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 681f80f339..af4b0e271b 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -279,6 +279,8 @@ void spl_board_init(void) { /* board specific spl init */ rk_spl_board_init(); + + preloader_console_init(); } #endif diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c index cddf4fd3d5..1c2dca8a72 100644 --- a/arch/arm/mach-rockchip/spl.c +++ b/arch/arm/mach-rockchip/spl.c @@ -147,7 +147,6 @@ void board_init_f(ulong dummy) gd->ram_top = gd->ram_base + get_effective_memsize(); gd->ram_top = board_get_usable_ram_top(gd->ram_size); #endif - preloader_console_init(); } #ifdef CONFIG_SPL_LOAD_FIT -- 2.20.1
[PATCH v3 3/5] roc-rk3399-pc: Move leds setup in SPL
roc-rk3399-pc has some specific requirements to support LEDS, environment. board detection and etc prior to U-Boot proper. So as of now SPL would be a better stage for these custom board requirements to support unlike TPL. Adding few of these custom requirements like LEDS in TPL would require extra code pulling and also the size of TPL can grow. So, this patch moves the leds code from TPL into SPL after relocation. Signed-off-by: Jagan Teki Tested-by: Suniel Mahesh --- Changes for v3: - new patch arch/arm/mach-rockchip/tpl.c| 7 --- board/firefly/roc-pc-rk3399/Makefile| 4 board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 21 --- board/firefly/roc-pc-rk3399/spl.c | 23 + configs/roc-pc-mezzanine-rk3399_defconfig | 2 +- configs/roc-pc-rk3399_defconfig | 2 +- 6 files changed, 29 insertions(+), 30 deletions(-) create mode 100644 board/firefly/roc-pc-rk3399/spl.c diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c index 88f80b05a9..cc908e1b0e 100644 --- a/arch/arm/mach-rockchip/tpl.c +++ b/arch/arm/mach-rockchip/tpl.c @@ -43,18 +43,11 @@ __weak void rockchip_stimer_init(void) TIMER_CONTROL_REG); } -__weak int board_early_init_f(void) -{ - return 0; -} - void board_init_f(ulong dummy) { struct udevice *dev; int ret; - board_early_init_f(); - #if defined(CONFIG_DEBUG_UART) && defined(CONFIG_TPL_SERIAL_SUPPORT) /* * Debug UART can be used from here if required: diff --git a/board/firefly/roc-pc-rk3399/Makefile b/board/firefly/roc-pc-rk3399/Makefile index 29c79b25d7..3a9c4c744d 100644 --- a/board/firefly/roc-pc-rk3399/Makefile +++ b/board/firefly/roc-pc-rk3399/Makefile @@ -4,4 +4,8 @@ # SPDX-License-Identifier: GPL-2.0+ # +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +else obj-y += roc-pc-rk3399.o +endif diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c index 7c3a803654..581cdcd3b0 100644 --- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c +++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c @@ -6,13 +6,8 @@ #include #include #include -#include #include -#include -#include -#include -#ifndef CONFIG_SPL_BUILD int board_early_init_f(void) { struct udevice *regulator; @@ -30,19 +25,3 @@ int board_early_init_f(void) out: return 0; } -#endif - -#if defined(CONFIG_TPL_BUILD) - -#define GPIO0_BASE 0xff72 - -int board_early_init_f(void) -{ - struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE; - - /* Turn on red LED, indicating full power mode */ - spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1); - - return 0; -} -#endif diff --git a/board/firefly/roc-pc-rk3399/spl.c b/board/firefly/roc-pc-rk3399/spl.c new file mode 100644 index 00..a7664c6b86 --- /dev/null +++ b/board/firefly/roc-pc-rk3399/spl.c @@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2020 Amarula Solutions(India) + */ + +#include +#include +#include + +#define GPIO0_BASE 0xff72 + +static void led_setup(void) +{ + struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE; + + /* Turn on red LED, indicating full power mode */ + spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1); +} + +void rk_spl_board_init(void) +{ + led_setup(); +} diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 03ba519af1..8ad74dc408 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 CONFIG_ENV_SECT_SIZE=0x1000 @@ -19,7 +20,6 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y -CONFIG_TPL_GPIO_SUPPORT=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index b59b54bd89..6fd06d6381 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 CONFIG_ENV_SECT_SIZE=0x1000 @@ -19,7 +20,6 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y -CONFIG_TPL_GPIO_SUPPORT=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y -- 2.20.1
[PATCH v3 4/5] rockchip: Separate the reset cause from display cpuinfo
reset cause is a generic functionality based on the soc cru registers in rockchip. This can be used for printing the cause of reset in cpuinfo or some other place where reset cause is needed. Other than cpuinfo, reset cause can also be using during bootcount for checking the specific reset cause and glow the led based on the reset cause. So, let's separate the reset cause code from cpuinfo, and add a check to build it for rk3399, rk3288 since these two soc are supporting reset cause as of now. Signed-off-by: Jagan Teki Tested-by: Suniel Mahesh --- Changes for v3: - none arch/arm/include/asm/arch-rockchip/cru.h | 2 ++ arch/arm/mach-rockchip/Makefile | 5 - arch/arm/mach-rockchip/cpu-info.c| 20 3 files changed, 18 insertions(+), 9 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/cru.h b/arch/arm/include/asm/arch-rockchip/cru.h index 5eb17f9d55..317eb61049 100644 --- a/arch/arm/include/asm/arch-rockchip/cru.h +++ b/arch/arm/include/asm/arch-rockchip/cru.h @@ -31,4 +31,6 @@ enum { #define MHz100 +char *get_reset_cause(void); + #endif /* _ROCKCHIP_CLOCK_H */ diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index 5b38526fe0..ef4898e00c 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -15,6 +15,10 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o +ifeq ($(CONFIG_ROCKCHIP_RK3288)$(CONFIG_ROCKCHIP_RK3399), y) +obj-y += cpu-info.o +endif + ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) # Always include boot_mode.o, as we bypass it (i.e. turn it off) @@ -22,7 +26,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) # we can have the preprocessor correctly recognise both 0x0 and 0 # meaning "turn it off". obj-y += boot_mode.o -obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o obj-$(CONFIG_MISC_INIT_R) += misc.o endif diff --git a/arch/arm/mach-rockchip/cpu-info.c b/arch/arm/mach-rockchip/cpu-info.c index 21ca9dedce..76a840e2c3 100644 --- a/arch/arm/mach-rockchip/cpu-info.c +++ b/arch/arm/mach-rockchip/cpu-info.c @@ -13,7 +13,7 @@ #include #include -static char *get_reset_cause(void) +char *get_reset_cause(void) { struct rockchip_cru *cru = rockchip_get_cru(); char *cause = NULL; @@ -41,12 +41,6 @@ static char *get_reset_cause(void) cause = "unknown reset"; } - /** -* reset_reason env is used by rk3288, due to special use case -* to figure it the boot behavior. so keep this as it is. -*/ - env_set("reset_reason", cause); - /* * Clear glb_rst_st, so we can determine the last reset cause * for following resets. @@ -56,12 +50,22 @@ static char *get_reset_cause(void) return cause; } +#ifdef CONFIG_DISPLAY_CPUINFO int print_cpuinfo(void) { + char *cause = get_reset_cause(); + printf("SoC: Rockchip %s\n", CONFIG_SYS_SOC); - printf("Reset cause: %s\n", get_reset_cause()); + printf("Reset cause: %s\n", cause); + + /** +* reset_reason env is used by rk3288, due to special use case +* to figure it the boot behavior. so keep this as it is. +*/ + env_set("reset_reason", cause); /* TODO print operating temparature and clock */ return 0; } +#endif -- 2.20.1
[PATCH v3 5/5] roc-rk3399-pc: Set LED only during POR and pwr_key=y
ROC-RK3399-PC has specific set of configurations for on-board led setup. Due to easiness for user to know the state of the board roc-rk339-pc board code will setup the low power led on/off, and waiting for user to press power key and then glow full power led. All this needs to happen only during power-on-reset not for soft reset or WDT. Also, it is not a proper usage to ask the user to press the Power key if the board connected remotely, so add the environment variable 'pwr_key' to check as well. So, user need to press Power key only - during POR - pwr_key=y Tested-by: Suniel Mahesh Signed-off-by: Jagan Teki --- Changes for v3: - new patch board/firefly/roc-pc-rk3399/spl.c | 35 ++- configs/roc-pc-mezzanine-rk3399_defconfig | 4 ++- configs/roc-pc-rk3399_defconfig | 4 ++- 3 files changed, 40 insertions(+), 3 deletions(-) diff --git a/board/firefly/roc-pc-rk3399/spl.c b/board/firefly/roc-pc-rk3399/spl.c index a7664c6b86..771a7fb2f2 100644 --- a/board/firefly/roc-pc-rk3399/spl.c +++ b/board/firefly/roc-pc-rk3399/spl.c @@ -4,16 +4,49 @@ */ #include +#include #include +#include +#include #include +#include +#define PMUGRF_BASE0xff32 #define GPIO0_BASE 0xff72 +/** + * LED setup for roc-rk3399-pc + * + * 1. Set the low power leds (only during POR, pwr_key env is 'y') + *glow yellow LED, termed as low power + *poll for on board power key press + *once powe key pressed, turn off yellow + * 2. Turn on red LED, indicating full power mode + */ static void led_setup(void) { struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE; + struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE; + bool press_pwr_key = false; + + if (IS_ENABLED(CONFIG_SPL_ENV_SUPPORT)) { + env_init(); + env_load(); + if (env_get_yesno("pwr_key") == 1) + press_pwr_key = true; + } + + if (press_pwr_key && !strcmp(get_reset_cause(), "POR")) { + spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1); + + spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), + GPIO_PULL_NORMAL); + while (readl(&gpio0->ext_port) & 0x20) + ; + + spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0); + } - /* Turn on red LED, indicating full power mode */ spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1); } diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 8ad74dc408..d3369063ea 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -17,7 +17,8 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2 +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y CONFIG_CMD_BOOTZ=y @@ -32,6 +33,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc-mezzanine" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index 6fd06d6381..0650b941c2 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -17,7 +17,8 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2 +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y CONFIG_CMD_BOOTZ=y @@ -31,6 +32,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y -- 2.20.1
Re: [PATCH] image: Add support for ZSTD decompression
On Wed, May 20, 2020 at 2:35 PM Tom Rini wrote: > > On Wed, May 20, 2020 at 01:38:01PM +0200, Robert Marko wrote: > > > Tom, > > I have tried various things but CONFIG_IS_ENABLED won't work inside of > > switch case. > > It works fine outside of if though. > > OK, thanks, I'll poke things more to make sure what I'm worried about > doesn't happen. Hi, were you able to test the commit? Regards, Robert > > -- > Tom
Re: Pull request: u-boot-rockchip-20200607
On Mon, Jun 08, 2020 at 03:23:33PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates/fixes: > - revive rk3399 puma board to adapt mainline dts; > - Fix rk3399-evb stdout path; > - Enable PCIe for rk3399: Rockpro64, firefly, pinebookpro; > - Add rk3328 Rock-pi-e board; > - Enable SPI boot for rockpro64 and roc-pc-rk3399; > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3580 > > Thanks, > - Kever > > The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140: > > configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20200607 > > for you to fetch changes up to 187ab38e766393cda7bf3bf4926c1e55f48ad0cb: > > rockchip: enable PCIe and NVMe on Pinebook Pro (2020-06-07 20:53:23 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: pull request of u-boot-mpc85xx for v2020.07
On Mon, Jun 08, 2020 at 07:32:47AM +, Priyanka Jain wrote: > Dear Tom, > Please find my pull-request for u-boot-mpc85xx > https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/694639674 > > Summary > DM_ETH support for P2041RDB, T1024RDB, P5040DS, P3041DS, P4080DS, bug fixes > Add TBI Phy access through MII > DDR: Rework errata workaround for A008109, A008378, 009942 > > Thanks > Priyanka Applied to u-boot/master, thanks! But please note and address: w+(P3041DS P3041DS_NAND P3041DS_SDCARD P3041DS_SPIFLASH) arch/powerpc/dts/p3041ds.dtb: Warning (avoid_default_addr_size): /localbus@ffe124000/board-control@3,0: Relying on default #address-cells value w+(P3041DS P3041DS_NAND P3041DS_SDCARD P3041DS_SPIFLASH) arch/powerpc/dts/p3041ds.dtb: Warning (avoid_default_addr_size): /localbus@ffe124000/board-control@3,0: Relying on default #size-cells value w+(P5040DS P5040DS_NAND P5040DS_SDCARD P5040DS_SPIFLASH) arch/powerpc/dts/p5040ds.dtb: Warning (avoid_default_addr_size): /localbus@ffe124000/board-control@3,0: Relying on default #address-cells value w+(P5040DS P5040DS_NAND P5040DS_SDCARD P5040DS_SPIFLASH) arch/powerpc/dts/p5040ds.dtb: Warning (avoid_default_addr_size): /localbus@ffe124000/board-control@3,0: Relying on default #size-cells value in follow-up patches, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 00/15] rockchip: Support building ROM files automatically
Rockchip-based Chromebooks support booting from SPI flash. It is annoying to have to manually build the SPI image when the SD image is built automatically. This feature is already available for x86 devices, so the existing mechanism is reused. Briefly, this allows a BUILD_ROM environment variable to be provided to indicate that any required binary blobs are present and it is safe to build the ROM. A new 'mkimage' type is added to binman to support building binaries with mkimage with a binman definition. This avoids Makefile/shell/Python code to do the same thing. This series uses binman to produce a ROM image on two selected Chromebooks, Bob (RK3399) and Jerry (RK3388). Simon Glass (15): dm: core Fix long line in device_bind_common() .gitignore: Ignore Python 3 cache directories binman: cbfs: Fix IFWI typo binman: Correct the search patch for pylibfdt binman: Add support for calling mkimage binman: Fix a few typos in the entry docs binman: Adjust pylibfdt for incremental build x86: rockchip: Change how selection of ROMs works rockchip: Allow Bob to use SPI boot Allow building .rom files for non-x86 boards rockchip: jerry: Add serial support rockchip: bob: Support SPI-flash booting rockchip: Allow including rockchip dtsi on 32-bit machines rockchip: Enable building a SPI ROM image on jerry rockchip: Enable building a SPI ROM image on bob .gitignore| 3 ++ Kconfig | 18 +++- Makefile | 30 ++--- arch/Kconfig | 1 + arch/arm/dts/rk3288-u-boot.dtsi | 24 +++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++ arch/arm/dts/rk3399-gru.dtsi | 2 +- arch/arm/dts/rk3399-u-boot.dtsi | 27 arch/arm/dts/rockchip-u-boot.dtsi | 10 - arch/arm/mach-rockchip/rk3288/Kconfig | 1 + arch/arm/mach-rockchip/rk3399/Kconfig | 1 + arch/arm/mach-rockchip/spl.c | 3 +- arch/x86/Kconfig | 4 ++ configs/chromebook_bob_defconfig | 4 +- configs/chromebook_jerry_defconfig| 1 + drivers/core/device.c | 3 +- scripts/dtc/pylibfdt/Makefile | 3 ++ tools/binman/README.entries | 27 +++- tools/binman/etype/_testing.py| 5 +++ tools/binman/etype/cbfs.py| 2 +- tools/binman/etype/mkimage.py | 62 +++ tools/binman/ftest.py | 7 +++ tools/binman/main.py | 2 +- tools/binman/test/156_mkimage.dts | 23 ++ 24 files changed, 252 insertions(+), 15 deletions(-) create mode 100644 tools/binman/etype/mkimage.py create mode 100644 tools/binman/test/156_mkimage.dts -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 04/15] binman: Correct the search patch for pylibfdt
Now that binman uses tools/ as its base directory for importing modules, the path to the pylibfdt build by U-Boot is incorrect. Fix it. Signed-off-by: Simon Glass --- tools/binman/main.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/binman/main.py b/tools/binman/main.py index efa7fa8386..4194761f9e 100755 --- a/tools/binman/main.py +++ b/tools/binman/main.py @@ -25,7 +25,7 @@ sys.path.insert(2, os.path.join(our_path, '..')) from patman import test_util # Bring in the libfdt module -sys.path.insert(2, 'scripts/dtc/pylibfdt') +sys.path.insert(2, os.path.join(our_path, '../../scripts/dtc/pylibfdt')) sys.path.insert(2, os.path.join(our_path, '../../build-sandbox_spl/scripts/dtc/pylibfdt')) -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 02/15] .gitignore: Ignore Python 3 cache directories
These can appear when moving between branches that have different tools in the tree. Ignore them. Signed-off-by: Simon Glass --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 2e1c8bf2bf..e66aa864da 100644 --- a/.gitignore +++ b/.gitignore @@ -92,3 +92,6 @@ GTAGS *.orig *~ \#*# + +# Python cache +__pycache__ -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 03/15] binman: cbfs: Fix IFWI typo
This comment references the wrong thing. Fix it. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/binman/etype/cbfs.py b/tools/binman/etype/cbfs.py index e9aed8310c..744a32fa0c 100644 --- a/tools/binman/etype/cbfs.py +++ b/tools/binman/etype/cbfs.py @@ -204,7 +204,7 @@ class Entry_cbfs(Entry): return True def _ReadSubnodes(self): -"""Read the subnodes to find out what should go in this IFWI""" +"""Read the subnodes to find out what should go in this CBFS""" for node in self._node.subnodes: entry = Entry.Create(self, node) entry.ReadNode() -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 01/15] dm: core Fix long line in device_bind_common()
Fix an over-length line in this function. Signed-off-by: Simon Glass --- drivers/core/device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/core/device.c b/drivers/core/device.c index a7408d9c76..2e3d555ea4 100644 --- a/drivers/core/device.c +++ b/drivers/core/device.c @@ -82,7 +82,8 @@ static int device_bind_common(struct udevice *parent, const struct driver *drv, * This is just a 'requested' sequence, and will be * resolved (and ->seq updated) when the device is probed. */ - if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) { + if (CONFIG_IS_ENABLED(OF_CONTROL) && + !CONFIG_IS_ENABLED(OF_PLATDATA)) { if (uc->uc_drv->name && ofnode_valid(node)) dev_read_alias_seq(dev, &dev->req_seq); #if CONFIG_IS_ENABLED(OF_PRIOR_STAGE) -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 05/15] binman: Add support for calling mkimage
As a first step to integrating mkimage into binman, add a new entry type that feeds data into mkimage for processing and incorporates that output into the image. Signed-off-by: Simon Glass --- tools/binman/README.entries | 23 tools/binman/etype/_testing.py| 5 +++ tools/binman/etype/mkimage.py | 62 +++ tools/binman/ftest.py | 7 tools/binman/test/156_mkimage.dts | 23 5 files changed, 120 insertions(+) create mode 100644 tools/binman/etype/mkimage.py create mode 100644 tools/binman/test/156_mkimage.dts diff --git a/tools/binman/README.entries b/tools/binman/README.entries index 6a816bba6b..4f2c48fdc2 100644 --- a/tools/binman/README.entries +++ b/tools/binman/README.entries @@ -587,6 +587,29 @@ See README.x86 for information about Intel binary blobs. +Entry: mkimage: Entry containing a binary produced by mkimage +- + +Properties / Entry arguments: +- datafile: Filename for -d argument +- args: Other arguments to pass + +The data passed to mkimage is collected from subnodes of the mkimage node, +e.g.: + +mkimage { +args = "-n test -T imximage"; + +u-boot-spl { +}; +}; + +This calls mkimage to create an imximage with u-boot-spl.bin as the input +file. The output from mkimage then becomes part of the image produced by +binman. + + + Entry: powerpc-mpc85xx-bootpg-resetvec: PowerPC mpc85xx bootpg + resetvec code for U-Boot - diff --git a/tools/binman/etype/_testing.py b/tools/binman/etype/_testing.py index ed718eed14..ea60561adb 100644 --- a/tools/binman/etype/_testing.py +++ b/tools/binman/etype/_testing.py @@ -57,6 +57,8 @@ class Entry__testing(Entry): 'return-contents-once') self.bad_update_contents_twice = fdt_util.GetBool(self._node, 'bad-update-contents-twice') +self.return_contents_later = fdt_util.GetBool(self._node, + 'return-contents-later') # Set to True when the entry is ready to process the FDT. self.process_fdt_ready = False @@ -83,6 +85,9 @@ class Entry__testing(Entry): def ObtainContents(self): if self.return_unknown_contents or not self.return_contents: return False +if self.return_contents_later: +self.return_contents_later = False +return False self.data = self.contents self.contents_size = len(self.data) if self.return_contents_once: diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py new file mode 100644 index 00..1aa563963a --- /dev/null +++ b/tools/binman/etype/mkimage.py @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (c) 2016 Google, Inc +# Written by Simon Glass +# +# Entry-type module for producing an image using mkimage +# + +from collections import OrderedDict + +from binman.entry import Entry +from dtoc import fdt_util +from patman import tools + +class Entry_mkimage(Entry): +"""Entry containing a binary produced by mkimage + +Properties / Entry arguments: +- datafile: Filename for -d argument +- args: Other arguments to pass + +The data passed to mkimage is collected from subnodes of the mkimage node, +e.g.: + +mkimage { +args = "-n test -T imximage"; + +u-boot-spl { +}; +}; + +This calls mkimage to create an imximage with u-boot-spl.bin as the input +file. The output from mkimage then becomes part of the image produced by +binman. +""" +def __init__(self, section, etype, node): +Entry.__init__(self, section, etype, node) +self._args = fdt_util.GetString(self._node, 'args').split(' ') +self._mkimage_entries = OrderedDict() +self._ReadSubnodes() + +def ObtainContents(self): +data = b'' +for entry in self._mkimage_entries.values(): +# First get the input data and put it in a file. If not available, +# try later. +if not entry.ObtainContents(): +return False +data += entry.GetData() +uniq = self.GetUniqueName() +input_fname = tools.GetOutputFilename('mkimage.%s' % uniq) +tools.WriteFile(input_fname, data) +output_fname = tools.GetOutputFilename('mkimage-out.%s' % uniq) +tools.Run('mkimage', '-d', input_fname, *self._args, output_fname) +self.SetContents(tools.ReadFile(output_fname)) +return True + +def _ReadSubnodes(self): +"""Read the subnodes to find out what should go in this image""" +for node in self._node.subnodes: +entry = Entry.Create(self, node) +
[PATCH 08/15] x86: rockchip: Change how selection of ROMs works
Most x86 boards build a u-boot.rom which is programmed into SPI flash. But this is not unique to x86. For example some rockchip boards can also boot from SPI flash. Also, at least on x86, binary blobs are sadly quite common. It is not possible to build a functional image without them, and U-Boot needs to know this at build time. Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary blobs are also needed. If they are not needed, it is safe to build the ROM always. Otherwise we still require the BUILD_ROM environment variable. For now this affects only x86, but future patches will enable this for rockchip too. Signed-off-by: Simon Glass --- Kconfig | 18 +- Makefile | 17 - arch/Kconfig | 1 + arch/x86/Kconfig | 4 4 files changed, 34 insertions(+), 6 deletions(-) diff --git a/Kconfig b/Kconfig index 0e7ccc0b07..876c5db911 100644 --- a/Kconfig +++ b/Kconfig @@ -240,9 +240,25 @@ config PHYS_64BIT This can be used not only for 64bit SoCs, but also for large physical address extension on 32bit SoCs. +config HAS_ROM + bool + select BINMAN + help + Enables building of a u-boot.rom target. This collects U-Boot and + any necessary binary blobs. + +config ROM_NEEDS_BLOBS + bool + depends on HAS_ROM + help + Enable this if building the u-boot.rom target needs binary blobs, and + so cannot be done normally. In this case, pass BUILD_ROM=1 to make + to tell U-Boot to build the ROM. + config BUILD_ROM bool "Build U-Boot as BIOS replacement" - depends on X86 + depends on HAS_ROM + default y if !ROM_NEEDS_BLOBS help This option allows to build a ROM version of U-Boot. The build process generally requires several binary blobs diff --git a/Makefile b/Makefile index db3b6b9991..d46338a6a4 100644 --- a/Makefile +++ b/Makefile @@ -916,9 +916,12 @@ ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf ALL-$(CONFIG_EFI_APP) += u-boot-app.efi ALL-$(CONFIG_EFI_STUB) += u-boot-payload.efi +ifneq ($(CONFIG_HAS_ROM),) ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),) -ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom +ALL-y += u-boot.rom endif +endif + ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy) ALL-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin endif @@ -1580,7 +1583,7 @@ endif # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in # the middle. This is handled by binman based on an image description in the # board's device tree. -ifneq ($(CONFIG_X86_RESET_VECTOR),) +ifneq ($(CONFIG_HAS_ROM),) rom: u-boot.rom FORCE refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE @@ -1590,11 +1593,12 @@ quiet_cmd_ldr = LD $@ cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \ $(filter-out FORCE,$^) -o $@ -u-boot.rom: u-boot-x86-start16.bin u-boot-x86-reset16.bin u-boot.bin \ +rom-deps := u-boot.bin +ifdef CONFIG_X86 +rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \ $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \ $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \ - $(if $(CONFIG_HAVE_REFCODE),refcode.bin) FORCE - $(call if_changed,binman) + $(if $(CONFIG_HAVE_REFCODE),refcode.bin) OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16 u-boot-x86-start16.bin: u-boot FORCE @@ -1603,6 +1607,9 @@ u-boot-x86-start16.bin: u-boot FORCE OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j .resetvec u-boot-x86-reset16.bin: u-boot FORCE $(call if_changed,objcopy) + +u-boot.rom: $(rom-deps) FORCE + $(call if_changed,binman) endif ifneq ($(CONFIG_ARCH_SUNXI),) diff --git a/arch/Kconfig b/arch/Kconfig index a11f872938..bc85e5b50b 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -160,6 +160,7 @@ config X86 select TIMER select USE_PRIVATE_LIBGCC select X86_TSC_TIMER + select HAS_ROM if X86_RESET_VECTOR imply BLK imply CMD_DM imply CMD_FPGA_LOADMK diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c8eae24c07..c688c46475 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -360,6 +360,8 @@ config HAVE_FSP bool "Add an Firmware Support Package binary" depends on !EFI select USE_HOB + select HAS_ROM + select ROM_NEEDS_BLOBS help Select this option to add an Firmware Support Package binary to the resulting U-Boot image. It is a binary blob which U-Boot uses @@ -519,6 +521,8 @@ config ENABLE_MRC_CACHE config HAVE_MRC bool "Add a System Agent binary" + select HAS_ROM + select ROM_NEEDS_BLOBS depends on !HAVE_FSP help Select this option to add a System Agent binary to -- 2.27.0.278.ge193c7cf3a9-goog
[PATCH 06/15] binman: Fix a few typos in the entry docs
Some typos have been fixed in the code but the entry docs were not regenerated. Fix this. Signed-off-by: Simon Glass --- tools/binman/README.entries | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/binman/README.entries b/tools/binman/README.entries index 4f2c48fdc2..d5b4b3af2b 100644 --- a/tools/binman/README.entries +++ b/tools/binman/README.entries @@ -519,7 +519,7 @@ Properties / Entry arguments: This file contains code used by the SoC that is required to make it work. The Management Engine is like a background task that runs things that are -not clearly documented, but may include keyboard, display and network +not clearly documented, but may include keyboard, deplay and network access. For platform that use ME it is not possible to disable it. U-Boot does not directly execute code in the ME binary. @@ -616,7 +616,7 @@ Entry: powerpc-mpc85xx-bootpg-resetvec: PowerPC mpc85xx bootpg + resetvec code f Properties / Entry arguments: - filename: Filename of u-boot-br.bin (default 'u-boot-br.bin') -This entry is valid for PowerPC mpc85xx cpus. This entry holds +This enrty is valid for PowerPC mpc85xx cpus. This entry holds 'bootpg + resetvec' code for PowerPC mpc85xx CPUs which needs to be placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'. -- 2.27.0.278.ge193c7cf3a9-goog