[PATCH] arm: imx: add u-boot-nand.imx to boot from NAND without SPL
U-Boot can be booted from NAND without SPL by prepending the DCD header to the actual U-Boot binary. However this requires prepending 1024 bytes to u-boot.imx (DCD + u-boot.bin). There is already a similar target to build spl/u-boot-nand-spl.imx, add the same option for no-SPL boot. Tested on i.MX6ULL. The resulting layout of u-boot-nand.imx is: - Offset 0x (0 KiB): padding - Offset 0x0400 (1 KiB): DCD header - Offset 0x1000 (4 KiB): u-boot.bin Signed-off-by: Luca Ceresoli --- Makefile | 3 +++ arch/arm/mach-imx/Makefile | 6 ++ 2 files changed, 9 insertions(+) diff --git a/Makefile b/Makefile index e760bacf9451..db124476d6e6 100644 --- a/Makefile +++ b/Makefile @@ -1522,6 +1522,9 @@ endif u-boot.uim: u-boot.bin FORCE $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ +u-boot-nand.imx: u-boot.imx FORCE + $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ + u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL $(if $(CONFIG_OF_SEPARATE),u-boot.img,u-boot.uim) FORCE $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 4dfc60eedc43..c386132dacd1 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -132,6 +132,12 @@ u-boot.imx: MKIMAGEOUTPUT = u-boot.imx.log u-boot.imx: u-boot.bin u-boot.cfgout $(PLUGIN).bin FORCE $(call if_changed,mkimage) +quiet_cmd_u-boot-nand_imx = GEN $@ +cmd_u-boot-nand_imx = (dd bs=1024 count=1 if=/dev/zero 2>/dev/null) | cat - $< > $@ + +u-boot-nand.imx: u-boot.imx FORCE + $(call if_changed,u-boot-nand_imx) + ifeq ($(CONFIG_MULTI_DTB_FIT),y) MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \ -T $(IMAGE_TYPE) -e $(CONFIG_TEXT_BASE) -- 2.34.1
Re: [PATCH 29/88] i2c: Rename I2C_MUX_PCA954x
Hi Simon, On Mon, 23 Jan 2023 14:59:32 -0700 Simon Glass wrote: > CONFIG options must not use lower-case letter. Convert this to upper case. > > Signed-off-by: Simon Glass > --- ... > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 2 +- FYI, this board has been removed from Michal's tree: https://lore.kernel.org/u-boot/093405ed-7e96-da00-cb7a-9ac3ad07b...@amd.com/ -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH v2] arm64: zynqmp: remove Avnet UltraZed-EV Starter Kit
Nobody seems interested and able to keep this board supported, and
xilinx_zynqmp_virt_defconfig is supposed to be enough for any zynqmp board.
See the discussion at:
https://lore.kernel.org/u-boot/CAPnjgZ3hHbyiFf=_Lp-Wz_XOWBkV-3vK4Q3xp=7bcerw-sp...@mail.gmail.com/T/#m76d726f1ab3f7074c8105c9a2af2110ac7d18708
Signed-off-by: Luca Ceresoli
---
Changed in v2:
- also remove board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/
(reported by Michal)
---
arch/arm/dts/Makefile | 1 -
...ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts | 59 --
arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi | 56 --
board/xilinx/zynqmp/MAINTAINERS | 6 -
.../psu_init_gpl.c| 655 --
...edev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 83 ---
6 files changed, 860 deletions(-)
delete mode 100644
arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
delete mode 100644 arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
delete mode 100644
board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
delete mode 100644
configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b3baaf482908..79bec315a2a5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -336,7 +336,6 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zybo-z7.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
- avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dtb\
zynqmp-a2197-revA.dtb \
zynqmp-dlc21-revA.dtb \
zynqmp-e-a2197-00-revA.dtb \
diff --git a/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
b/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
deleted file mode 100644
index 6d1448e8697a..
--- a/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
+++ /dev/null
@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-
-/*
- * UltraZed-EV Carrier Card v1 (based on the UltraZed-EV SoM)
- * http://ultrazed.org/product/ultrazed-ev-carrier-card
- */
-
-/dts-v1/;
-
-#include "avnet-ultrazedev-som-v1.0.dtsi"
-
-/ {
- model = "Avnet UltraZed EV Carrier Card v1.0";
- compatible = "avnet,ultrazedev-cc-v1.0-ultrazedev-som-v1.0",
-"xlnx,zynqmp";
- chosen {
- stdout-path = "serial0:115200n8";
- };
- aliases {
- ethernet0 =
- nvmem0 =
- serial0 =
- };
-};
-
- {
- device_type = "serial";
- status = "okay";
-};
-
-_cc {
- /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROM with EUI-48 */
- eeprom: eeprom@51 {
- compatible = "atmel,24c02";
- reg = <0x51>;
- };
-
- /* IDT Versa Clock 5P49V5935B */
- vc5: clock-generator@6a {
- compatible = "idt,5p49v5935";
- reg = <0x6a>;
- #clock-cells = <1>;
- };
-};
-
-/* Ethernet RJ-45 */
- {
- status = "okay";
-};
-
-/* microSD card slot */
- {
- status = "okay";
- xlnx,mio-bank = <1>;
- clock-frequency = <18000>;
- max-frequency = <5000>;
- no-1-8-v;
- disable-wp;
-};
diff --git a/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
b/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
deleted file mode 100644
index cbcb290a5c83..
--- a/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-
-/*
- * UltraZed-EV SoM v1
- * http://ultrazed.org/product/ultrazed-ev
- */
-
-/dts-v1/;
-
-#include "zynqmp.dtsi"
-#include "zynqmp-clk-ccf.dtsi"
-
-/ {
- model = "Avnet UltraZed EV SoM v1.0";
- compatible = "avnet,ultrazedev-som-v1.0", "xlnx,zynqmp";
- memory {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>, /* 2 GB @ offset 0 */
- <0x8 0x0 0x0 0x8000>; /* 2 GB @ offset 32GB */
- };
-};
-
- {
- clock-frequency = <40>;
- status = "okay";
-
- i2cswitch@70 {
- compatible = "nxp,pca9543";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x70>;
-
- /* I2C connected to Carrier Card via JX3A1/JX3C1 */
- i2c_cc: i2c@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
- };
-};
-
-/* Marvell 88E1512-A0-NNP2I000 Ethernet PHY */
- {
- phy-mode = "rgmii-id";
- phy-h
[PATCH] arm64: zynqmp: remove Avnet UltraZed-EV Starter Kit
Nobody seems interested and able to keep this board supported, and
xilinx_zynqmp_virt_defconfig is supposed to be enough for any zynqmp board.
See the discussion at:
https://lore.kernel.org/u-boot/CAPnjgZ3hHbyiFf=_Lp-Wz_XOWBkV-3vK4Q3xp=7bcerw-sp...@mail.gmail.com/T/#m76d726f1ab3f7074c8105c9a2af2110ac7d18708
Signed-off-by: Luca Ceresoli
---
arch/arm/dts/Makefile | 1 -
...ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts | 59 -
arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi | 56 -
board/xilinx/zynqmp/MAINTAINERS | 6 --
...edev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 83 ---
5 files changed, 205 deletions(-)
delete mode 100644
arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
delete mode 100644 arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
delete mode 100644
configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b3baaf482908..79bec315a2a5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -336,7 +336,6 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zybo-z7.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
- avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dtb\
zynqmp-a2197-revA.dtb \
zynqmp-dlc21-revA.dtb \
zynqmp-e-a2197-00-revA.dtb \
diff --git a/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
b/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
deleted file mode 100644
index 6d1448e8697a..
--- a/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
+++ /dev/null
@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-
-/*
- * UltraZed-EV Carrier Card v1 (based on the UltraZed-EV SoM)
- * http://ultrazed.org/product/ultrazed-ev-carrier-card
- */
-
-/dts-v1/;
-
-#include "avnet-ultrazedev-som-v1.0.dtsi"
-
-/ {
- model = "Avnet UltraZed EV Carrier Card v1.0";
- compatible = "avnet,ultrazedev-cc-v1.0-ultrazedev-som-v1.0",
-"xlnx,zynqmp";
- chosen {
- stdout-path = "serial0:115200n8";
- };
- aliases {
- ethernet0 =
- nvmem0 =
- serial0 =
- };
-};
-
- {
- device_type = "serial";
- status = "okay";
-};
-
-_cc {
- /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROM with EUI-48 */
- eeprom: eeprom@51 {
- compatible = "atmel,24c02";
- reg = <0x51>;
- };
-
- /* IDT Versa Clock 5P49V5935B */
- vc5: clock-generator@6a {
- compatible = "idt,5p49v5935";
- reg = <0x6a>;
- #clock-cells = <1>;
- };
-};
-
-/* Ethernet RJ-45 */
- {
- status = "okay";
-};
-
-/* microSD card slot */
- {
- status = "okay";
- xlnx,mio-bank = <1>;
- clock-frequency = <18000>;
- max-frequency = <5000>;
- no-1-8-v;
- disable-wp;
-};
diff --git a/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
b/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
deleted file mode 100644
index cbcb290a5c83..
--- a/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-
-/*
- * UltraZed-EV SoM v1
- * http://ultrazed.org/product/ultrazed-ev
- */
-
-/dts-v1/;
-
-#include "zynqmp.dtsi"
-#include "zynqmp-clk-ccf.dtsi"
-
-/ {
- model = "Avnet UltraZed EV SoM v1.0";
- compatible = "avnet,ultrazedev-som-v1.0", "xlnx,zynqmp";
- memory {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x8000>, /* 2 GB @ offset 0 */
- <0x8 0x0 0x0 0x8000>; /* 2 GB @ offset 32GB */
- };
-};
-
- {
- clock-frequency = <40>;
- status = "okay";
-
- i2cswitch@70 {
- compatible = "nxp,pca9543";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x70>;
-
- /* I2C connected to Carrier Card via JX3A1/JX3C1 */
- i2c_cc: i2c@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
- };
-};
-
-/* Marvell 88E1512-A0-NNP2I000 Ethernet PHY */
- {
- phy-mode = "rgmii-id";
- phy-handle = <>;
- gem3phy: ethernet-phy@0 {
- reg = <0>;
- };
-};
-
-/* Micron MTFC8GAKAJCN-4M 8 GB eMMC */
- {
- status = "okay";
- xlnx,mio-bank = <0>;
- clock-frequency = <18000>;
-};
d
Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default
Hello Tom, Simon, Michal, On Sun, 8 Jan 2023 12:36:15 -0700 Simon Glass wrote: > Hi Tom, > > On Sun, 8 Jan 2023 at 09:24, Tom Rini wrote: > > > > On Sun, Jan 08, 2023 at 09:20:09AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sun, 8 Jan 2023 at 09:06, Tom Rini wrote: > > > > > > > > On Sun, Jan 08, 2023 at 08:48:37AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Sun, 8 Jan 2023 at 06:41, Tom Rini wrote: > > > > > > > > > > > > On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote: > > > > > > > > > > > > > This option is deprecated and only used by two boards. Enable it > > > > > > > for just > > > > > > > those two boards, so others don't accidentally enable it. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > [snip] > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > > index 55f06761ef8..7ab0dd14211 100644 > > > > > > > --- a/boot/Kconfig > > > > > > > +++ b/boot/Kconfig > > > > > > > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE > > > > > > > config USE_SPL_FIT_GENERATOR > > > > > > > bool "Use a script to generate the .its script" > > > > > > > depends on SPL_FIT > > > > > > > - default y if SPL_FIT && ARCH_ZYNQMP > > > > > > > + help > > > > > > > + This is deprecated. Please do not use it. Use binman > > > > > > > instead. > > > > > > > > > > > > Lets remove the text around bool so it can't be enabled, and move to > > > > > > select'ing it from the two boards that need it. Michal, Luca, what's > > > > > > needed to move your two platforms > > > > > > (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and > > > > > > xilinx_zynqmp_virt off > > > > > > of this very legacy option, given that other xilinx platforms have > > > > > > already migrated to binman ? Unfortunately I lost access to that board, and since the vendor does not appear interested in supporting it I think the best options would be to either remove the defconfig or to keep legacy support. Which one would you prefer? Regards, -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH] board/xilinx/zynqmp/MAINTAINERS: change e-mail address for Luca Ceresoli
My Bootlin address is the preferred one now. Signed-off-by: Luca Ceresoli Signed-off-by: Luca Ceresoli --- board/xilinx/zynqmp/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/xilinx/zynqmp/MAINTAINERS b/board/xilinx/zynqmp/MAINTAINERS index 17a2766413c6..07b91b81c95b 100644 --- a/board/xilinx/zynqmp/MAINTAINERS +++ b/board/xilinx/zynqmp/MAINTAINERS @@ -11,7 +11,7 @@ F:configs/xilinx_zynqmp* F: configs/avnet_ultra96_rev1_defconfig ARM ZYNQMP AVNET ULTRAZED EV BOARD -M: Luca Ceresoli +M: Luca Ceresoli S: Maintained F: arch/arm/dts/avnet-ultrazedev-* F: configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig -- 2.34.1
Re: [PATCH] arm64: zynqmp: Do not include psu_init to U-Boot by default
Hello Michal,
Il 02/12/22 09:18, Michal Simek ha scritto:
> The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
> Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
> default which is not correct configuration.
> Intention of this config was to have it enabled by default for SPL and
> provide an option to users to also do low level initialization directly
> from U-Boot.
> That's why it is necessary to define second symbol with SPL marking in it
> and properly use symbols depends on usage in Makefile.
> Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
> default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
> is enabled.
>
> Reported-by: Venkatesh Yadav Abbarapu
> Signed-off-by: Michal Simek
After checking ed35de617013 I can see the problem, and this seems like a
correct fix:
Reviewed-by: Luca Ceresoli
--
Luca
[PATCH] tools/zynqmp_pm_cfg_obj_convert.py: fix build with Vivado 2021.x
This tool fails with a pm_cfg_obj.c file generated by Vitis 2021.2. This is
because that version of Vitis added the PM_CONFIG_OBJECT_TYPE_BASE that was
not previously generated, thus the script does not implement it.
Reported-by: Neal Frager
[report:
https://lists.buildroot.org/pipermail/buildroot/2022-February/636639.html]
Signed-off-by: Luca Ceresoli
---
tools/zynqmp_pm_cfg_obj_convert.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/zynqmp_pm_cfg_obj_convert.py
b/tools/zynqmp_pm_cfg_obj_convert.py
index 0a44710e1e14..239991a5263c 100755
--- a/tools/zynqmp_pm_cfg_obj_convert.py
+++ b/tools/zynqmp_pm_cfg_obj_convert.py
@@ -244,6 +244,8 @@ pm_define = {
'SUSPEND_TIMEOUT': 0x,
+'PM_CONFIG_OBJECT_TYPE_BASE' : 0x1,
+
'PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK' : 0x0001,
'PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK' : 0x0100,
'PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK' : 0x0200,
--
2.25.1
Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver
Hi Adam, On 03/06/21 14:06, Adam Ford wrote: > On Thu, Jun 3, 2021 at 3:34 AM Luca Ceresoli wrote: >> >> On 24/05/21 19:53, Adam Ford wrote: >>> The driver is based on the Versaclock driver from the Linux code, but >>> do differences in the clock API between them, some pieces had to change. >> >> s/do/due to/ ? >> s/had to change/had to be changed/ > > I am usually more careful about grammar. I must have been tired. :-) > >> >>> This driver creates a mux, pfd, pll, and a series of fod ouputs. >>> Rate Usecnt Name >>> -- >>> 2500 0`-- x304-clock >>> 2500 0`-- clock-control...@6a.mux >>> 2500 0|-- clock-control...@6a.pfd >>> 28 0| `-- clock-control...@6a.pll >>> 0| |-- clock-controller@6a.fod0 >>> 0| | `-- >>> clock-controller@6a.out1 >>> 0| |-- clock-controller@6a.fod1 >>> 0| | `-- >>> clock-controller@6a.out2 >>> 5000 0| |-- clock-controller@6a.fod2 >>> 5000 0| | `-- >>> clock-controller@6a.out3 >>> 125000| `-- clock-controller@6a.fod3 >>> 125000| `-- >>> clock-controller@6a.out4 >>> 2500 0`-- clock-controller@6a.out0_sel_i2cb >>> >>> A translation function is added so the references to < X> get >>> routed >>> to the corresponding clock-control...@6a.outx. >>> >>> Signed-off-by: Adam Ford >> >> I've been reviewing this patch and it looks mostly OK to me except for a >> few notes below, mostly minor ones. However my knowledge of the U-Boot >> driver model is minimal, thus I couldn't go in depth in the most >> interesting and critical part of Adam's work, i.e. the adaptations for >> the U-Boot codebase. I'm afraid I cannot do more. >> >>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile >>> index 645709b855..2a9ebec860 100644 >>> --- a/drivers/clk/Makefile >>> +++ b/drivers/clk/Makefile >>> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o >>> obj-$(CONFIG_STM32H7) += clk_stm32h7.o >>> obj-$(CONFIG_CLK_VERSAL) += clk_versal.o >>> obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o >>> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o >> >> Nit: space after '+='. > > make sense. > >> >>> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c >>> new file mode 100644 >>> index 00..30e49fad31 >>> --- /dev/null >>> +++ b/drivers/clk/clk_versaclock.c >>> @@ -0,0 +1,1025 @@ >>> +// SPDX-License-Identifier: GPL-2.0-or-later >>> +/* >>> + * Driver for IDT Versaclock 5/6 >>> + * >>> + * Derived from code Copyright (C) 2017 Marek Vasut >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >> >> Missing file? > > This was included a while ago in order to allow the device trees to build. Apologies, I was on an old commit and didn't realize. -- Luca
Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver
On 24/05/21 19:53, Adam Ford wrote:
> The driver is based on the Versaclock driver from the Linux code, but
> do differences in the clock API between them, some pieces had to change.
s/do/due to/ ?
s/had to change/had to be changed/
> This driver creates a mux, pfd, pll, and a series of fod ouputs.
> Rate Usecnt Name
> --
> 2500 0`-- x304-clock
> 2500 0`-- clock-control...@6a.mux
> 2500 0|-- clock-control...@6a.pfd
> 28 0| `-- clock-control...@6a.pll
> 0| |-- clock-controller@6a.fod0
> 0| | `--
> clock-controller@6a.out1
> 0| |-- clock-controller@6a.fod1
> 0| | `--
> clock-controller@6a.out2
> 5000 0| |-- clock-controller@6a.fod2
> 5000 0| | `--
> clock-controller@6a.out3
> 125000| `-- clock-controller@6a.fod3
> 125000| `--
> clock-controller@6a.out4
> 2500 0`-- clock-controller@6a.out0_sel_i2cb
>
> A translation function is added so the references to < X> get
> routed
> to the corresponding clock-control...@6a.outx.
>
> Signed-off-by: Adam Ford
I've been reviewing this patch and it looks mostly OK to me except for a
few notes below, mostly minor ones. However my knowledge of the U-Boot
driver model is minimal, thus I couldn't go in depth in the most
interesting and critical part of Adam's work, i.e. the adaptations for
the U-Boot codebase. I'm afraid I cannot do more.
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 645709b855..2a9ebec860 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
> obj-$(CONFIG_STM32H7) += clk_stm32h7.o
> obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
> obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
Nit: space after '+='.
> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
> new file mode 100644
> index 00..30e49fad31
> --- /dev/null
> +++ b/drivers/clk/clk_versaclock.c
> @@ -0,0 +1,1025 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Driver for IDT Versaclock 5/6
> + *
> + * Derived from code Copyright (C) 2017 Marek Vasut
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
Missing file?
> +
> +/* VersaClock5 registers */
> +#define VC5_OTP_CONTROL 0x00
> +
> +/* Factory-reserved register block */
> +#define VC5_RSVD_DEVICE_ID 0x01
> +#define VC5_RSVD_ADC_GAIN_7_00x02
> +#define VC5_RSVD_ADC_GAIN_15_8 0x03
> +#define VC5_RSVD_ADC_OFFSET_7_0 0x04
> +#define VC5_RSVD_ADC_OFFSET_15_8 0x05
> +#define VC5_RSVD_TEMPY 0x06
> +#define VC5_RSVD_OFFSET_TBIN 0x07
> +#define VC5_RSVD_GAIN0x08
> +#define VC5_RSVD_TEST_NP 0x09
> +#define VC5_RSVD_UNUSED 0x0a
> +#define VC5_RSVD_BANDGAP_TRIM_UP 0x0b
> +#define VC5_RSVD_BANDGAP_TRIM_DN 0x0c
> +#define VC5_RSVD_CLK_R_12_CLK_AMP_4 0x0d
> +#define VC5_RSVD_CLK_R_34_CLK_AMP_4 0x0e
> +#define VC5_RSVD_CLK_AMP_123 0x0f
I wonder whether it really makes sense to define so many registers that
are not used in the driver. But it's done the same way in the Linux
driver, and it doesn't hurt much, so I'll be fine with or without them.
[...]
> +static const struct udevice_id versaclock_ids[] = {
> + { .compatible = "idt,5p49v5923", .data = (ulong)_5p49v5923_info },
> + { .compatible = "idt,5p49v5925", .data = (ulong)_5p49v5925_info },
> + { .compatible = "idt,5p49v5933", .data = (ulong)_5p49v5933_info },
> + { .compatible = "idt,5p49v5935", .data = (ulong)_5p49v5935_info },
> + { .compatible = "idt,5p49v6901", .data = (ulong)_5p49v6901_info },
> + { .compatible = "idt,5p49v6965", .data = (ulong)_5p49v6965_info },
> + {},
> +};
Why not putting this array below, right before the U_BOOT_DRIVER() call
where it is used, similarly to the Linux driver?
--
Luca
Re: [PATCH v2] tools: zynqmp: Fix regex expression around XPm_ConfigObject.
Hi,
On 24/11/20 16:13, Adrian Fiergolski wrote:
> The XPm_ConfigObject array definition generated by Vitis 2020.1 differs from
> previous Vivado versions (before 2019.2).
>
> -const u32 XPm_ConfigObject[] __attribute__((used, section(".sys_cfg_data")))
> = {
> +const u32 XPm_ConfigObject[] __attribute__((used, section(".sys_cfg_data")))
> =
> +#elif defined (__ICCARM__)
> +#pragma location = ".sys_cfg_data"
> +__root const u32 XPm_ConfigObject[] =
> +#endif
> +{
>
> Change the matching regex to handle both cases.
>
> Signed-off-by: Adrian Fiergolski
> ---
> Changes in v2:
> Fix the patch tile.
>
> tools/zynqmp_pm_cfg_obj_convert.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/zynqmp_pm_cfg_obj_convert.py
> b/tools/zynqmp_pm_cfg_obj_convert.py
> index dd27f47921..0a44710e1e 100755
> --- a/tools/zynqmp_pm_cfg_obj_convert.py
> +++ b/tools/zynqmp_pm_cfg_obj_convert.py
> @@ -289,7 +289,7 @@ code = in_file.read()
> code = re.sub('//.*?\n|/\*.*?\*/', '', code, flags=re.DOTALL)
>
> # remove everything outside the XPm_ConfigObject array definition
> -code = re.search('const u32 XPm_ConfigObject.*= {\n(.*)};',
> +code = re.search('const u32 XPm_ConfigObject.*=.*{\n(.*)};',
> code, flags=re.DOTALL).group(1)
Looks good, thanks.
Reviewed-by: Luca Ceresoli
--
Luca
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi, On 23/06/20 23:23, Luca Ceresoli wrote: > Hi Brandon, > > On 23/06/20 19:08, Brandon Maier wrote: >> On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli wrote: >>> >>> Hi Brandon, >>> >>> On 22/06/20 22:45, Brandon Maier wrote: >>>> To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the >>>> U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert >>>> their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file >>>> back to U-Boot during build. >>>> >>>> Instead, by doing the conversion in U-Boot during the build, we can >>>> simplify the developer's build system. And it ensures that if >>>> zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in >>>> sync with U-Boot. >>> >>> In the workflows I have used so far U-Boot tools are extracted in a >>> different step w.r.t. U-Boot cross-compilation, so I never felt the need >>> for this feature. But I understand this feature can be handy. >> >> I'm trying to get it to work with Buildroot. Buildroot does have a >> package for uboot-tools, so I could use that to run it. I'd have to >> move the config and build commands into Buildroot's uboot package. >> Since the script belongs to U-Boot anyway, it seemed cleaner to >> integrate it directly into U-Boot so it could be used by other build >> systems too. > > I understand. But I also understand Michal's concern: the U-Boot > makefiles are quite complex already, and this feature is a relatively > minor improvement. > > Probably having the conversion in Buildroot could be even simpler as you > can support _only_ the C format there and do the conversion > unconditionally. Only one workflow, no ifs, simpler code. Don't forget > to Cc: me if you send a patch for that, I'll be glad to review it. I almost forgot: I wrote some notes on how this could be implemented in yocto a while back. The principles are pretty much the same so you might be interested in reading them: https://www.yoctoproject.org/pipermail/meta-xilinx/2019-November/004578.html -- Luca
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi Brandon, On 23/06/20 19:08, Brandon Maier wrote: > On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli wrote: >> >> Hi Brandon, >> >> On 22/06/20 22:45, Brandon Maier wrote: >>> To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the >>> U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert >>> their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file >>> back to U-Boot during build. >>> >>> Instead, by doing the conversion in U-Boot during the build, we can >>> simplify the developer's build system. And it ensures that if >>> zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in >>> sync with U-Boot. >> >> In the workflows I have used so far U-Boot tools are extracted in a >> different step w.r.t. U-Boot cross-compilation, so I never felt the need >> for this feature. But I understand this feature can be handy. > > I'm trying to get it to work with Buildroot. Buildroot does have a > package for uboot-tools, so I could use that to run it. I'd have to > move the config and build commands into Buildroot's uboot package. > Since the script belongs to U-Boot anyway, it seemed cleaner to > integrate it directly into U-Boot so it could be used by other build > systems too. I understand. But I also understand Michal's concern: the U-Boot makefiles are quite complex already, and this feature is a relatively minor improvement. Probably having the conversion in Buildroot could be even simpler as you can support _only_ the C format there and do the conversion unconditionally. Only one workflow, no ifs, simpler code. Don't forget to Cc: me if you send a patch for that, I'll be glad to review it. -- Luca
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi Brandon, On 22/06/20 22:45, Brandon Maier wrote: > To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the > U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert > their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file > back to U-Boot during build. > > Instead, by doing the conversion in U-Boot during the build, we can > simplify the developer's build system. And it ensures that if > zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in > sync with U-Boot. In the workflows I have used so far U-Boot tools are extracted in a different step w.r.t. U-Boot cross-compilation, so I never felt the need for this feature. But I understand this feature can be handy. The code looks OK too. Reviewed-by: Luca Ceresoli -- Luca
Re: [PATCHv2 29/31] spi: Enable missing CONFIG_SPL_DM_SPI support
Hi, On 17/06/20 01:06, Tom Rini wrote: > Due to how the Makefile logic is we currently get DM_SPI support in SPL > enabled by having DM_SPI enabled for full U-Boot but not having > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > inadvertently making use of it. [...] For the Avnet Ultrazed: > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 + Reviewed-by: Luca Ceresoli -- Luca
Re: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
Hi Tom, On 10/06/20 22:16, Tom Rini wrote: > Due to how the Makefile logic is we currently get DM_SPI support in SPL > enabled by having DM_SPI enabled for full U-Boot but not having > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > inadvertently making use of it. > > Cc: Adam Ford > Cc: Akash Gajjar > Cc: Anatolij Gustschin > Cc: Andy Yan > Cc: Anup Patel > Cc: Atish Patra > Cc: Bin Meng > Cc: Chee Hong Ang > Cc: Chin-Liang See > Cc: Dalon Westergreen > Cc: Dinh Nguyen > Cc: Eugen Hristev > Cc: Hannes Schmelzer > Cc: Heiko Schocher > Cc: Jagan Teki > Cc: Klaus Goger > Cc: Levin Du > Cc: Ley Foon Tan > Cc: Lokesh Vutla > Cc: Luca Ceresoli > Cc: Marek Vasut > Cc: Michal Simek > Cc: Mike Looijmans > Cc: Nicolas Ferre > Cc: Nikita Kiryanov > Cc: Palmer Dabbelt > Cc: Patrick Delaunay > Cc: Paul Walmsley > Cc: Pavel Machek > Cc: Peter Robinson > Cc: Philipp Tomsich > Cc: Simon Glass > Cc: Stefan Roese > Cc: Suniel Mahesh > Cc: Wolfgang Grandegger > Signed-off-by: Tom Rini For the Avnet Ultrazed: > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 + Reviewed-by: Luca Ceresoli -- Luca
Re: [PATCH] serial: Convert ARM_DCC to Kconfig
On 02/06/20 23:26, Tom Rini wrote: > The symbol "CONFIG_ARM_DCC" is used to control building > drivers/serial/arm_dcc.c. Provide a simple Kconfig entry for this. > > Cc: Luca Ceresoli > Cc: Michal Simek > Cc: Tom McLeod > Cc: Mike Looijmans > Signed-off-by: Tom Rini Reviewed-by: Luca Ceresoli -- Luca
[PATCH 1/2] board: ti: am57xx: use GPIO_TO_PIN() to define GPIO number
Using the macro makes code readable without the need for a comment. Signed-off-by: Luca Ceresoli --- board/ti/am57xx/board.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c index 8720eb87a55d..c41aa24f957b 100644 --- a/board/ti/am57xx/board.c +++ b/board/ti/am57xx/board.c @@ -68,8 +68,7 @@ static int board_bootmode_has_emmc(void); DECLARE_GLOBAL_DATA_PTR; #define GPIO_ETH_LCD GPIO_TO_PIN(2, 22) -/* GPIO 7_11 */ -#define GPIO_DDR_VTT_EN 203 +#define GPIO_DDR_VTT_ENGPIO_TO_PIN(7, 11) /* Touch screen controller to identify the LCD */ #define OSD_TS_FT_BUS_ADDRESS 0 -- 2.26.2
[PATCH 2/2] board: ti: use positive logic to detect idk boards
am57x_idk_lcd_detect() exits immediately if a known board not having
an LCD is found, i.e. a non-IDK board. This is annoying as we have to
remember to add an extra OR clause for every new non-IDK board.
Add a board_is_ti_idk() macro so that the logic becomes positive (detect
LCD on IDK boards instead of not-known-without-LCD boards). Even more
important, add the macro just below the board_is_*_idk() macros, so it is
easy to remember to update it when adding a new IDK.
Signed-off-by: Luca Ceresoli
---
board/ti/am57xx/board.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index c41aa24f957b..511858a5e90c 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -61,6 +61,10 @@ static int board_bootmode_has_emmc(void);
#define board_is_am571x_idk() board_ti_is("AM571IDK")
#define board_is_bbai()board_ti_is("BBONE-AI")
+#define board_is_ti_idk() board_is_am574x_idk() || \
+ board_is_am572x_idk() || \
+ board_is_am571x_idk()
+
#ifdef CONFIG_DRIVER_TI_CPSW
#include
#endif
@@ -666,7 +670,7 @@ void am57x_idk_lcd_detect(void)
struct udevice *dev;
/* Only valid for IDKs */
- if (board_is_x15() || board_is_am572x_evm() || board_is_bbai())
+ if (!board_is_ti_idk())
return;
/* Only AM571x IDK has gpio control detect.. so check that */
--
2.26.2
Re: [PATCH] firmware: zynqmp: Change panic logic in zynqmp_pmufw_load_config_object()
Hi Michal, On 12/05/20 08:25, Michal Simek wrote: > There is no need to panic all the time when pmufw config object loading > failed. The patch improves function logic to report permission deny case > and also panic only for SPL case. > > Signed-off-by: Michal Simek Looks good to me. Reviewed-by: Luca Ceresoli -- Luca
Re: [PATCH] i2c: muxes: pca954x: add PCA9546 variant
Hi Chris, On 01/04/20 04:55, Chris Packham wrote: > This adds the PCA9546 4-channel i2c bus switch. > > Signed-off-by: Chris Packham Reviewed-by: Luca Ceresoli -- Luca
Re: [U-Boot] [PATCH] firmware: zynqmp: Clean up zynqmp_power_probe
Hi,
On 10/10/19 11:33, Michal Simek wrote:
> Fix error debug messages to be more accurate and aligned with debug message
> style in the whole file.
> And do not initialize ret variable because it is initialized later on and
> it is just additional step.
>
> Fixes: 1327d1678bd2 ("firmware: zynqmp: Add zynqmp-power support")
> Reported-by: Luca Ceresoli
> Signed-off-by: Michal Simek
Reviewed-by: Luca Ceresoli
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] firmware: zynqmp: Report error when xilinx_pm_request called from EL3
Hi, On 10/10/19 11:13, Michal Simek wrote: > Function should report error when called in EL3 context. Also report it as > error instead 0 (success). > > Reported-by: Luca Ceresoli > Signed-off-by: Michal Simek > --- > > Based on https://lists.denx.de/pipermail/u-boot/2019-October/385462.html > series. Reviewed-by: Luca Ceresoli -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm64: xilinx: Move firmware functions from platform to driver
> #include
> +#include
>
> #if defined(CONFIG_ZYNQMP_IPI)
> #include
> -#include
> #include
>
> #define PMUFW_PAYLOAD_ARG_CNT8
> @@ -147,6 +147,42 @@ U_BOOT_DRIVER(zynqmp_power) = {
> };
> #endif
>
> +int __maybe_unused invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2,
> + u32 arg3, u32 *ret_payload)
> +{
> + /*
> + * Added SIP service call Function Identifier
> + * Make sure to stay in x0 register
> + */
> + struct pt_regs regs;
> +
> + if (current_el() == 3)
> + return 0;
Not stated in the log message, but this check does not exist in current
invoke_smc(). It's useful to check as it avoids a big explosion in case
invoke_smc is called in the wrong context.
But, if possible, it would be good to emit an error here, or the failure
would be silent. Does this look correct?
But that would be another patch, so:
Reviewed-by: Luca Ceresoli
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/13] firmware: zynqmp: Add zynqmp-power support
Hi,
On 02/10/19 15:39, Michal Simek wrote:
> From: Ibai Erkiaga
>
> zynqmp-power driver for ZynqMP to handle the communication with the PMU
> firmware. Firmware driver just probes subnodes and power driver handles
> communication with PMU using the IPI mailbox driver.
>
> Signed-off-by: Ibai Erkiaga
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Check error separately - Reported by Luca
>
> drivers/firmware/Kconfig | 2 ++
> drivers/firmware/firmware-zynqmp.c | 44 ++
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index b70a2063551c..9596ec16c7f7 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -30,6 +30,8 @@ config TI_SCI_PROTOCOL
> config ZYNQMP_FIRMWARE
> bool "ZynqMP Firmware interface"
> select FIRMWARE
> + select ZYNQMP_IPI
> + select DM_MAILBOX
Nitpick: ZYNQMP_IPI depends on DM_MAILBOX, so I'd list them in opposite
order. Just for clarity.
> help
> Firmware interface driver is used by different
> drivers to communicate with the firmware for
> diff --git a/drivers/firmware/firmware-zynqmp.c
> b/drivers/firmware/firmware-zynqmp.c
> index 6644a7166ca0..97ac333296ec 100644
> --- a/drivers/firmware/firmware-zynqmp.c
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -1,6 +1,50 @@
> // SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Zynq MPSoC Firmware driver
> + *
> + * Copyright (C) 2018-2019 Xilinx, Inc.
> + */
>
> +#include
> #include
> +#include
> +#include
> +
> +struct zynqmp_power {
> + struct mbox_chan tx_chan;
> + struct mbox_chan rx_chan;
> +} zynqmp_power;
> +
> +static int zynqmp_power_probe(struct udevice *dev)
> +{
> + int ret = 0;
No need to initialize.
> +
> + debug("%s, (dev=%p)\n", __func__, dev);
> +
> + ret = mbox_get_by_name(dev, "tx", _power.tx_chan);
> + if (ret) {
> + debug("%s, cannot tx mailbox\n", __func__);
"cannot tx" -> "cannot find tx"?
> + return ret;
> + }
> +
> + ret = mbox_get_by_name(dev, "rx", _power.rx_chan);
> + if (ret)
> + debug("%s, cannot rx mailbox\n", __func__);
Ditto.
> +
> + return ret;
return 0;
PS: I think some of the above are fixed in later patches, but some are
still valid.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/13] mailbox: zynqmp: ipi mailbox driver
Hi Ibai, Michal,
I had half-written a review of this patch and patch 4. Unfortunately I
didn't finish them before they got applied. I'll send them now anyway,
they are mostly nitpicking but you might consider them for a future
improvement. Sorry for the inconvenience.
On 02/10/19 15:39, Michal Simek wrote:
> From: Ibai Erkiaga
>
> ZynqMP mailbox driver implementing IPI communication with PMU. This would
> allow U-Boot SPL to communicate with PMUFW to request privileged
> operations.
>
> Signed-off-by: Ibai Erkiaga
> Signed-off-by: Michal Simek
...
> +static int zynqmp_ipi_probe(struct udevice *dev)
> +{
> + struct zynqmp_ipi *zynqmp = dev_get_priv(dev);
> + struct resource res;
> + ofnode node;
> +
> + debug("%s(dev=%p)\n", __func__, dev);
> +
> + /* Get subnode where the regs are defined */
> + /* Note IPI mailbox node needs to be the first one in DT */
> + node = ofnode_first_subnode(dev_ofnode(dev));
> +
> + if (ofnode_read_resource_byname(node, "local_request_region", )) {
> + dev_err(dev, "No reg property for local_request_region\n");
> + return -EINVAL;
> + };
> + zynqmp->local_req_regs = devm_ioremap(dev, res.start,
> + (res.start - res.end));
> +
> + if (ofnode_read_resource_byname(node, "local_response_region", )) {
> + dev_err(dev, "No reg property for local_response_region\n");
> + return -EINVAL;
> + };
> + zynqmp->local_res_regs = devm_ioremap(dev, res.start,
> + (res.start - res.end));
> +
> + if (ofnode_read_resource_byname(node, "remote_request_region", )) {
> + dev_err(dev, "No reg property for remote_request_region\n");
> + return -EINVAL;
> + };
> + zynqmp->remote_req_regs = devm_ioremap(dev, res.start,
> +(res.start - res.end));
> +
> + if (ofnode_read_resource_byname(node, "remote_response_region", )) {
> + dev_err(dev, "No reg property for remote_response_region\n");
> + return -EINVAL;
> + };
> + zynqmp->remote_res_regs = devm_ioremap(dev, res.start,
> +(res.start - res.end));
remote_req_regs and remote_res_regs are not used, why adding them in DT?
Should there be a good reason to keep them, I think the above code could
be reorganized to avoid code duplication (assuming binary size of a
bootloader still matters nowadays).
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/13] arm64: zynqmp: Cleanup PM SMC macro composition
Hi Michal,
On 02/10/19 11:36, Michal Simek wrote:
> On 02. 10. 19 11:34, Luca Ceresoli wrote:
>> Hi Michal,
>>
>> On 27/09/19 15:34, Michal Simek wrote:
>>> Cleanup PM ID handling by using enum values.
>>>
>>> Signed-off-by: Michal Simek
>>> Signed-off-by: Ibai Erkiaga
>>> ---
>>>
>>> arch/arm/mach-zynqmp/include/mach/sys_proto.h | 13 +++--
>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
>>> b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
>>> index f25d414dcb1e..573c4ffceed9 100644
>>> --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
>>> +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
>>> @@ -10,7 +10,8 @@
>>> #define PAYLOAD_ARG_CNT5
>>>
>>> #define ZYNQMP_CSU_SILICON_VER_MASK0xF
>>> -#define ZYNQMP_SIP_SVC_PM_SECURE_IMG_LOAD 0xC22D
>>> +#define ZYNQMP_SIP_SVC_PM_SECURE_IMG_LOAD \
>>> + (PM_SIP_SVC + PM_SECURE_IMAGE)
>>> #define KEY_PTR_LEN32
>>>
>>> #define ZYNQMP_FPGA_BIT_AUTH_DDR 1
>>> @@ -21,7 +22,8 @@
>>>
>>> #define ZYNQMP_FPGA_AUTH_DDR 1
>>>
>>> -#define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
>>> +#define ZYNQMP_SIP_SVC_GET_API_VERSION \
>>> + (PM_SIP_SVC + PM_GET_API_VERSION)
>>>
>>> #define ZYNQMP_PM_VERSION_MAJOR1
>>> #define ZYNQMP_PM_VERSION_MINOR0
>>> @@ -36,6 +38,13 @@
>>>
>>> #define PMUFW_V1_0 ((1 << ZYNQMP_PM_VERSION_MAJOR_SHIFT) | 0)
>>>
>>> +#define PM_SIP_SVC 0xc200
>>> +
>>> +enum pm_api_id {
>>> + PM_GET_API_VERSION = 1,
>>> + PM_SECURE_IMAGE = 45,
>>> +};
>>> +
>>
>> This is a matter of personal taste, but I prefer to define values before
>> using them. So unless there is a good reason to define these values here
>> I'd rather move them before.
>
> ZYNQMP_SIP_SVC.. macros are still used. It is just changing a way how
> they are defined because PM_SIP_SVC is really just SMC identification.
My point is about order of lines in the file, not about patch order in
the series.
Let me clarify. The lines where PM_SECURE_IMAGE is used is above the
line there it is declared. Same for PM_GET_API_VERSION. I would (in this
same patch) declare enum pm_api_id above in the file.
I hope it is clearer now, sorry for the confusion.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] firmware: zynqmp: Separate function for sending message via mailbox
Hi Michal,
On 27/09/19 15:35, Michal Simek wrote:
> U-Boot running in EL3 can't use SMC that's why there is a need to talk to
> PMUFW directly via mailbox. The same logic is applied to all functions
> which need to talk to PMUFW that's why move this logic to separate function
> to avoid code duplication.
>
> Also SMC request ID can be composed from PM_SIP_SVC offset that's why
> ZYNQMP_SIP_SVC_GET_API_VERSION macro can be removed completely.
>
> Signed-off-by: Michal Simek
> ---
>
> drivers/firmware/firmware-zynqmp.c | 19 ++-
> include/zynqmp_firmware.h | 2 --
> 2 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/firmware/firmware-zynqmp.c
> b/drivers/firmware/firmware-zynqmp.c
> index d70f34f24388..b7e3039c8337 100644
> --- a/drivers/firmware/firmware-zynqmp.c
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -40,6 +40,14 @@ static int ipi_req(const u32 *req, size_t req_len, u32
> *res, size_t res_maxlen)
> return 0;
> }
>
> +static int send_req(const u32 *req, size_t req_len, u32 *res, size_t
> res_maxlen)
> +{
> + if (IS_ENABLED(CONFIG_SPL_BUILD))
> + return ipi_req(req, req_len, res, 2);
I guess the last parameter should be res_maxlen, not 2.
Other than than, looks good.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/13] arm64: zynqmp: Cleanup PM SMC macro composition
Hi Michal,
On 27/09/19 15:34, Michal Simek wrote:
> Cleanup PM ID handling by using enum values.
>
> Signed-off-by: Michal Simek
> Signed-off-by: Ibai Erkiaga
> ---
>
> arch/arm/mach-zynqmp/include/mach/sys_proto.h | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> index f25d414dcb1e..573c4ffceed9 100644
> --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
> @@ -10,7 +10,8 @@
> #define PAYLOAD_ARG_CNT 5
>
> #define ZYNQMP_CSU_SILICON_VER_MASK 0xF
> -#define ZYNQMP_SIP_SVC_PM_SECURE_IMG_LOAD0xC22D
> +#define ZYNQMP_SIP_SVC_PM_SECURE_IMG_LOAD\
> + (PM_SIP_SVC + PM_SECURE_IMAGE)
> #define KEY_PTR_LEN 32
>
> #define ZYNQMP_FPGA_BIT_AUTH_DDR 1
> @@ -21,7 +22,8 @@
>
> #define ZYNQMP_FPGA_AUTH_DDR 1
>
> -#define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
> +#define ZYNQMP_SIP_SVC_GET_API_VERSION \
> + (PM_SIP_SVC + PM_GET_API_VERSION)
>
> #define ZYNQMP_PM_VERSION_MAJOR 1
> #define ZYNQMP_PM_VERSION_MINOR 0
> @@ -36,6 +38,13 @@
>
> #define PMUFW_V1_0 ((1 << ZYNQMP_PM_VERSION_MAJOR_SHIFT) | 0)
>
> +#define PM_SIP_SVC 0xc200
> +
> +enum pm_api_id {
> + PM_GET_API_VERSION = 1,
> + PM_SECURE_IMAGE = 45,
> +};
> +
This is a matter of personal taste, but I prefer to define values before
using them. So unless there is a good reason to define these values here
I'd rather move them before.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] arm64: zynqmp: Use mailbox driver for PMUFW config loading
Hi Michal, On 27/09/19 15:35, Michal Simek wrote: > With new mailbox driver PMUFW configuration object can be loaded via the > same interface and there is no need to have pmu_ipc.c completely. > > Signed-off-by: Michal Simek > --- > > arch/arm/mach-zynqmp/Makefile | 4 - > arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 - > arch/arm/mach-zynqmp/pmu_ipc.c| 112 -- Goodbye, beloved pmu_ipc.c... :) Reviewed-by: Luca Ceresoli -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] firmware: zynqmp: Add zynqmp-power support
Hi Ibai, Michal,
On 27/09/19 15:34, Michal Simek wrote:
> From: Ibai Erkiaga
>
> zynqmp-power driver for ZynqMP to handle the communication with the PMU
> firmware. Firmware driver just probes subnodes and power driver handles
> communication with PMU using the IPI mailbox driver.
>
> Signed-off-by: Ibai Erkiaga
> Signed-off-by: Michal Simek
> ---
>
> drivers/firmware/Kconfig | 2 ++
> drivers/firmware/firmware-zynqmp.c | 40 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index b70a2063551c..9596ec16c7f7 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -30,6 +30,8 @@ config TI_SCI_PROTOCOL
> config ZYNQMP_FIRMWARE
> bool "ZynqMP Firmware interface"
> select FIRMWARE
> + select ZYNQMP_IPI
> + select DM_MAILBOX
> help
> Firmware interface driver is used by different
> drivers to communicate with the firmware for
> diff --git a/drivers/firmware/firmware-zynqmp.c
> b/drivers/firmware/firmware-zynqmp.c
> index 6644a7166ca0..b0930447b988 100644
> --- a/drivers/firmware/firmware-zynqmp.c
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -1,6 +1,46 @@
> // SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Zynq MPSoC Firmware driver
> + *
> + * Copyright (C) 2018-2019 Xilinx, Inc.
> + */
>
> +#include
> #include
> +#include
> +#include
> +
> +struct zynqmp_power {
> + struct mbox_chan tx_chan;
> + struct mbox_chan rx_chan;
> +} zynqmp_power;
> +
> +static int zynqmp_power_probe(struct udevice *dev)
> +{
> + int ret = 0;
> +
> + debug("%s, (dev=%p)\n", __func__, dev);
> +
> + ret |= mbox_get_by_name(dev, "tx", _power.tx_chan);
> + ret |= mbox_get_by_name(dev, "rx", _power.rx_chan);
If these two calls return different error values, the binary or will
produce a nonsense 'ret' value. E.g. (-EINVAL | -ENODATA) equals -ENOTDIR.
Otherwise looks good.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] arm64: zynqmp: Clean communication with PMUFW
Hi Michal, Ibai, On 27/09/19 15:34, Michal Simek wrote: > Hi, > > This patch series using ZynqMP firmware driver to provide a interface to > communicate with the PMU Firmware. As part of the series a mailbox driver > is also implemented to handle communication through ipi interface. > > There are two new wiring: > 1. Reading PMUFW version via firmware driver > - mailbox driver in case of SPL > - SMC in case of full U-Boot > 2. Using the same patch for loading PMUFW configuration object > > The whole series is based on several patches I have sent already that's why > I am providing a branch which also contains this series. > https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze/tree/next > > Thanks, > Michal Good to see this work going on, thanks! I can't review in detail most of the patches, but I'm still replying with some (mostly minor) comments. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm64: zynqmp: Define default SYS_PROMPT
Hi Michal, On 25/09/19 12:38, Michal Simek wrote: > All boards are using the same prompt that's why add it as default value to > Kconfig to simplify defconfigs. > > Signed-off-by: Michal Simek > --- > > cmd/Kconfig| 1 + > configs/avnet_ultra96_rev1_defconfig | 1 - > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 - > configs/xilinx_zynqmp_a2197_g_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_m_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_p_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_revA_defconfig | 1 - > configs/xilinx_zynqmp_mini_defconfig | 1 - > configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - > configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - > configs/xilinx_zynqmp_mini_nand_defconfig | 1 - > configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - > configs/xilinx_zynqmp_zc1232_revA_defconfig| 1 - > configs/xilinx_zynqmp_zc1254_revA_defconfig| 1 - > configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 - > configs/xilinx_zynqmp_zcu100_revC_defconfig| 1 - > configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 - > configs/xilinx_zynqmp_zcu102_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu102_revB_defconfig| 1 - > configs/xilinx_zynqmp_zcu104_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu104_revC_defconfig| 1 - > configs/xilinx_zynqmp_zcu106_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu111_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu1275_revA_defconfig | 1 - > configs/xilinx_zynqmp_zcu1275_revB_defconfig | 1 - > 29 files changed, 1 insertion(+), 28 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index ab65f87999dc..65360a69beb6 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -49,6 +49,7 @@ config SYS_LONGHELP > config SYS_PROMPT > string "Shell prompt" > default "Zynq> " if ARCH_ZYNQ > + default "ZynqMP> " if ARCH_ZYNQMP > default "=> " Generally speaking, why do we need a per-machine prompt at all? "=> " ought be enough for everybody, nope? However to maintain backward compatibility with whatever expects those prompts this patch is a good cleanup anyway: Reviewed-by: Luca Ceresoli -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: Define default SPL_TEXT_BASE address in Kconfig
Hi Michal,
On 11/09/19 07:54, Michal Simek wrote:
> Define default address via Kconfig. There is no need to change this address
> for most of the boards but it is also possible. This one line save a lot of
> lines in defconfigs that's why make sense to do it.
>
> The similar change has been done by commit 9340d8fe8beb
> ("sunxi: move CONFIG_SPL_TEXT_BASE from *_defconfig to Kconfig")
>
> Signed-off-by: Michal Simek
Reviewed-by: Luca Ceresoli
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm64: zynqmp: add MAINTAINERS entry for Avnet UltraZed-EV
The board was added without adding a MAINTAINERS entry. Fixes: $ ./tools/genboardscfg.py -f WARNING: no status info for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' WARNING: no maintainers for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' $ Reported-by: Michal Simek Signed-off-by: Luca Ceresoli --- Changes v1 -> v2: - add to board/xilinx/zynqmp/MAINTAINERS, not the top-level file (Michal) - add the dts files (Michal) - explicitly mention the "EV" board variant --- board/xilinx/zynqmp/MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/board/xilinx/zynqmp/MAINTAINERS b/board/xilinx/zynqmp/MAINTAINERS index e6fed25152ac..1671c6eed2d8 100644 --- a/board/xilinx/zynqmp/MAINTAINERS +++ b/board/xilinx/zynqmp/MAINTAINERS @@ -6,3 +6,9 @@ F: board/xilinx/zynqmp/ F: include/configs/xilinx_zynqmp* F: configs/xilinx_zynqmp* F: configs/avnet_ultra96_rev1_defconfig + +ARM ZYNQMP AVNET ULTRAZED EV BOARD +M: Luca Ceresoli +S: Maintained +F: arch/arm/dts/avnet-ultrazedev-* +F: configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig -- 2.22.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: add MAINTAINERS entry for Avnet UltraZed
Hi Michal, On 20/06/19 08:03, Michal Simek wrote: > On 19. 06. 19 18:28, Luca Ceresoli wrote: >> The board was added without adding a MAINTAINERS entry. >> >> Fixes: >> >> $ ./tools/genboardscfg.py -f >> WARNING: no status info for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' >> WARNING: no maintainers for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' >> $ >> >> Reported-by: Michal Simek >> Signed-off-by: Luca Ceresoli >> --- >> MAINTAINERS | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 8e26eda2c887..29751901d752 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -420,6 +420,12 @@ F: tools/zynqmp* >> N: ultra96 >> N: zynqmp >> >> +ARM ZYNQMP AVNET ULTRAZED BOARD >> +M: Luca Ceresoli >> +S: Maintained > > you also need to cover dts files. > >> +F: configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig >> +N: ultrazed >> + >> ARM ZYNQMP R5 >> M: Michal Simek >> S: Maintained >> > > Please add it here board/xilinx/zynqmp/MAINTAINERS > > That high level MAINTAINERS file is used for archs/platforms code. > Your part is really only for board configs. Oh, sure! v2 incoming. Thanks, -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: add MAINTAINERS entry for Avnet UltraZed
The board was added without adding a MAINTAINERS entry. Fixes: $ ./tools/genboardscfg.py -f WARNING: no status info for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' WARNING: no maintainers for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' $ Reported-by: Michal Simek Signed-off-by: Luca Ceresoli --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8e26eda2c887..29751901d752 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -420,6 +420,12 @@ F: tools/zynqmp* N: ultra96 N: zynqmp +ARM ZYNQMP AVNET ULTRAZED BOARD +M: Luca Ceresoli +S: Maintained +F: configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig +N: ultrazed + ARM ZYNQMP R5 M: Michal Simek S: Maintained -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Hi Michal, On 19/06/19 09:20, Michal Simek wrote: [...] >> I have removed this line and applied this patch. > > Can you please also send a patch to create maintainer fragment for this > board? > > [u-boot](sdhci2)$ ./tools/genboardscfg.py -f > WARNING: no status info for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' > WARNING: no maintainers for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0' > > Please put it to board/xilinx/zynqmp/MAINTAINERS I had considered adding one in my original patch, but MAINTAINERS was looking like it contains only maintainers for big stuff so I thought it was a good idea not to add a simple board defconfig. I was wrong, sorry. Patch incoming, thanks for reporting. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
only publicly-available compatible carrier card. The SoM is based on the EV
version of the Xilinx ZynqMP SoC+FPGA.
The psu_init_gpl.c file has been generated from the board definition files
at [0] using Vivado 2018.3 and then minimized by
tools/zynqmp_psu_init_minimize.sh. Manually removed serdes init code since
it is not mentioned in device tree and fixed a checkpatch error.
[0]
https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
Signed-off-by: Luca Ceresoli
---
Changes v2 -> v3 (Michal):
- add board version to DT file names (v1 for both SoM and carrier)
- DT: add model and compatible properties to both SoM and CC
- DT: remove port-number property from uart0
- DT: fix compatible string for eeprom
- DT: fix ethernet phy nodes
- psu_init: replace "return (0)" -> "return 0"
Changes v1 -> v2:
- remove serdes code from psu_init_gpl.c since no serdes is enabled in DT
(Michal)
- split DT in two files: SOM and carrier card (Michal)
- improved DT comments, added product URLs
- DT: add missing phy-handle under ethernet node (Michal)
Whole patchset tested on:
- current u-boot/master, as is
- current u-boot-microblaze/master
---
arch/arm/dts/Makefile | 1 +
...ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts | 60 ++
arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi | 56 ++
.../psu_init_gpl.c| 663 ++
...edev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 64 ++
5 files changed, 844 insertions(+)
create mode 100644
arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
create mode 100644 arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
create mode 100644
board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
create mode 100644
configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e0c54bfa767e..a6764ba53581 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -238,6 +238,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zybo-z7.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
+ avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dtb\
zynqmp-mini.dtb \
zynqmp-mini-emmc0.dtb \
zynqmp-mini-emmc1.dtb \
diff --git a/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
b/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
new file mode 100644
index ..9a05a9f7c37c
--- /dev/null
+++ b/arch/arm/dts/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/*
+ * UltraZed-EV Carrier Card v1 (based on the UltraZed-EV SoM)
+ * http://ultrazed.org/product/ultrazed-ev-carrier-card
+ */
+
+/dts-v1/;
+
+#include "avnet-ultrazedev-som-v1.0.dtsi"
+
+/ {
+ model = "Avnet UltraZed EV Carrier Card v1.0";
+ compatible = "avnet,ultrazedev-cc-v1.0-ultrazedev-som-v1.0",
+"xlnx,zynqmp";
+ chosen {
+ stdout-path = "serial0:115200n8";
+ xlnx,eeprom =
+ };
+ aliases {
+ ethernet0 =
+ serial0 =
+ };
+};
+
+ {
+ device_type = "serial";
+ status = "okay";
+ u-boot,dm-pre-reloc;
+};
+
+_cc {
+ /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROM with EUI-48 */
+ eeprom: eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ };
+
+ /* IDT Versa Clock 5P49V5935B */
+ vc5: clock-generator@6a {
+ compatible = "idt,5p49v5935";
+ reg = <0x6a>;
+ #clock-cells = <1>;
+ };
+};
+
+/* Ethernet RJ-45 */
+ {
+ status = "okay";
+};
+
+/* microSD card slot */
+ {
+ status = "okay";
+ xlnx,mio_bank = <1>;
+ clock-frequency = <18000>;
+ max-frequency = <5000>;
+ no-1-8-v;
+ disable-wp;
+};
diff --git a/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
b/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
new file mode 100644
index ..b635db649f43
--- /dev/null
+++ b/arch/arm/dts/avnet-ultrazedev-som-v1.0.dtsi
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/*
+ * UltraZed-EV SoM v1
+ * http://ultrazed.org/product/ultrazed-ev
+ */
+
+/dts-v1/;
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+
+/ {
+ model = "Avnet UltraZed EV SoM v1.0";
+ compatible = "avnet,ultrazedev-som-v1.0", "xlnx,zynqmp";
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8
[U-Boot] [PATCH v3 1/2] tools/zynqmp_psu_init_minimize.sh: fix return lines coding style
Remove unneeded parenthess around return value. E.g.:
return (0); -> return 0;
Signed-off-by: Luca Ceresoli
---
tools/zynqmp_psu_init_minimize.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/zynqmp_psu_init_minimize.sh
b/tools/zynqmp_psu_init_minimize.sh
index b0a07f9080a6..384bb56e1a16 100755
--- a/tools/zynqmp_psu_init_minimize.sh
+++ b/tools/zynqmp_psu_init_minimize.sh
@@ -94,6 +94,9 @@ sed -i 's/^unsigned long /static &/g' ${OUT}
sed -i 's/()$/(void)/g' ${OUT}
sed -i 's/0X/0x/g' ${OUT}
+# return (0) -> return 0
+sed -ri 's/return \(([0-9]+)\)/return \1/g' ${OUT}
+
# Add header
cat << EOF >${TMP}
// SPDX-License-Identifier: GPL-2.0+
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Hi Michal,
On 28/05/19 09:45, Michal Simek wrote:
[...]
>> +static unsigned long psu_ddr_phybringup_data(void)
>> +{
>> +unsigned int regval = 0;
>> +unsigned int pll_retry = 10;
>> +unsigned int pll_locked = 0;
>> +
>> +while ((pll_retry > 0) && (!pll_locked)) {
>> +Xil_Out32(0xFD080004, 0x00040010);
>> +Xil_Out32(0xFD080004, 0x00040011);
>> +
>> +while ((Xil_In32(0xFD080030) & 0x1) != 1)
>> +;
>> +pll_locked = (Xil_In32(0xFD080030) & 0x8000)
>> +>> 31;
>> +pll_locked &= (Xil_In32(0xFD0807E0) & 0x1)
>> +>> 16;
>> +pll_locked &= (Xil_In32(0xFD0809E0) & 0x1)
>> +>> 16;
>> +pll_locked &= (Xil_In32(0xFD080BE0) & 0x1)
>> +>> 16;
>> +pll_locked &= (Xil_In32(0xFD080DE0) & 0x1)
>> +>> 16;
>> +pll_retry--;
>> +}
>> +Xil_Out32(0xFD0800C4, Xil_In32(0xFD0800C4) | (pll_retry << 16));
>> +if (!pll_locked)
>> +return (0);
>
> nit: return 0;
In v3 I'm sending a new patch to let tools/zynqmp_psu_init_minimize.sh
do it automatically.
Ok for the other change requests too, will be in v3.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
only publicly-available compatible carrier card. The SoM is based on the EV
version of the Xilinx ZynqMP SoC+FPGA.
The psu_init_gpl.c file has been generated from the board definition files
at [0] using Vivado 2018.3 and then minimized by
tools/zynqmp_psu_init_minimize.sh. Manually removed serdes init code since
it is not mentioned in device tree and fixed a checkpatch error.
[0]
https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
Signed-off-by: Luca Ceresoli
---
Changes v1 -> v2:
- remove serdes code from psu_init_gpl.c since no serdes is enabled in DT
(Michal)
- split DT in two files: SOM and carrier card (Michal)
- improved DT comments, added product URLs
- DT: add missing phy-handle under ethernet node (Michal)
Whole patchset tested on:
- current u-boot/master, as is
- current u-boot-microblaze/master
- current u-boot-microblaze/master with the addtion of
commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/avnet-ultrazedev-cc.dts | 58 ++
arch/arm/dts/avnet-ultrazedev-som.dtsi| 54 ++
.../zynqmp/avnet-ultrazedev-cc/psu_init_gpl.c | 663 ++
configs/avnet_ultrazedev_defconfig| 64 ++
5 files changed, 840 insertions(+)
create mode 100644 arch/arm/dts/avnet-ultrazedev-cc.dts
create mode 100644 arch/arm/dts/avnet-ultrazedev-som.dtsi
create mode 100644 board/xilinx/zynqmp/avnet-ultrazedev-cc/psu_init_gpl.c
create mode 100644 configs/avnet_ultrazedev_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8167cdb4e856..d82dc6529749 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zybo-z7.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
+ avnet-ultrazedev-cc.dtb \
zynqmp-mini.dtb \
zynqmp-mini-emmc0.dtb \
zynqmp-mini-emmc1.dtb \
diff --git a/arch/arm/dts/avnet-ultrazedev-cc.dts
b/arch/arm/dts/avnet-ultrazedev-cc.dts
new file mode 100644
index ..d94dd4246f7b
--- /dev/null
+++ b/arch/arm/dts/avnet-ultrazedev-cc.dts
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/*
+ * UltraZed-EV Carrier Card (based on the UltraZed-EV SoM)
+ * http://ultrazed.org/product/ultrazed-ev-carrier-card
+ */
+
+/dts-v1/;
+
+#include "avnet-ultrazedev-som.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ xlnx,eeprom =
+ };
+ aliases {
+ ethernet0 =
+ serial0 =
+ };
+};
+
+ {
+ device_type = "serial";
+ port-number = <0>;
+ status = "okay";
+ u-boot,dm-pre-reloc;
+};
+
+_cc {
+ /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROM with EUI-48 */
+ eeprom: eeprom@51 {
+ compatible = "at,24c02", "i2c-eeprom";
+ reg = <0x51>;
+ };
+
+ /* IDT Versa Clock 5P49V5935B */
+ vc5: clock-generator@6a {
+ compatible = "idt,5p49v5935";
+ reg = <0x6a>;
+ #clock-cells = <1>;
+ };
+};
+
+/* Ethernet RJ-45 */
+ {
+ status = "okay";
+};
+
+/* microSD card slot */
+ {
+ status = "okay";
+ xlnx,mio_bank = <1>;
+ clock-frequency = <18000>;
+ max-frequency = <5000>;
+ no-1-8-v;
+ disable-wp;
+};
diff --git a/arch/arm/dts/avnet-ultrazedev-som.dtsi
b/arch/arm/dts/avnet-ultrazedev-som.dtsi
new file mode 100644
index ..4ce0a2d31786
--- /dev/null
+++ b/arch/arm/dts/avnet-ultrazedev-som.dtsi
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/*
+ * UltraZed-EV SoM
+ * http://ultrazed.org/product/ultrazed-ev
+ */
+
+/dts-v1/;
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>, /* 2 GB @ offset 0 */
+ <0x8 0x0 0x0 0x8000>; /* 2 GB @ offset 32GB */
+ };
+};
+
+ {
+ clock-frequency = <40>;
+ status = "okay";
+
+ i2cswitch@70 {
+ compatible = "nxp,pca9543";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ /* I2C connected to Carrier Card via JX3A1/JX3C1 */
+ i2c_cc: i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+}
[U-Boot] [PATCH v2 1/3] arm64: zynqmp: xil_io.h: declare functions as static
Fixes sparse warnings when building zynqmp defconfigs:
./board/xilinx/zynqmp/xil_io.h:12:6: warning: symbol 'Xil_Out32' was not
declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:17:5: warning: symbol 'Xil_In32' was not
declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:22:6: warning: symbol 'usleep' was not
declared. Should it be static?
Also add __maybe_unused to usleep() since it is not used by minimized
psu_init_gpl.c files, so it would warn as "defined but not used".
Signed-off-by: Luca Ceresoli
---
Chages v1 -> v2:
- fix commit text (Michal)
---
board/xilinx/zynqmp/xil_io.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/zynqmp/xil_io.h b/board/xilinx/zynqmp/xil_io.h
index c476c902ebcb..1c1bf32adaae 100644
--- a/board/xilinx/zynqmp/xil_io.h
+++ b/board/xilinx/zynqmp/xil_io.h
@@ -9,17 +9,17 @@
#define xil_printf(...)
-void Xil_Out32(unsigned long addr, unsigned long val)
+static void Xil_Out32(unsigned long addr, unsigned long val)
{
writel(val, addr);
}
-int Xil_In32(unsigned long addr)
+static int Xil_In32(unsigned long addr)
{
return readl(addr);
}
-void usleep(u32 sleep)
+static void __maybe_unused usleep(u32 sleep)
{
udelay(sleep);
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] arm64: zynqmp: add tool to minimize psu_init_gpl.c files
This script transforms a pair of psu_init_gpl.c and .h files produced by
the Xilinx Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that
is almost checkpatch compliant.
Based on a script by Michal Simek.
Signed-off-by: Luca Ceresoli
---
Changes v1 -> v2:
- document that is INPUT_DIR==OUTPUT_DIR then psu_init_gpl.c is overwritten
- minor improvement to commit message
- show help text if script is called without parameters (Michal)
---
tools/zynqmp_psu_init_minimize.sh | 145 ++
1 file changed, 145 insertions(+)
create mode 100755 tools/zynqmp_psu_init_minimize.sh
diff --git a/tools/zynqmp_psu_init_minimize.sh
b/tools/zynqmp_psu_init_minimize.sh
new file mode 100755
index ..b0a07f9080a6
--- /dev/null
+++ b/tools/zynqmp_psu_init_minimize.sh
@@ -0,0 +1,145 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2018 Michal Simek
+# Copyright (C) 2019 Luca Ceresoli
+
+usage()
+{
+cat </
+
+Notes: INPUT_DIR must contain both .c and .h files.
+ If INPUT_DIR and OUTPUT_DIR are the same directory,
+ psu_init_gpl.c will be overwritten.
+
+EOF
+}
+
+set -o errexit -o errtrace
+set -o nounset
+
+if [ $# -ne 2 ]
+then
+usage >&2
+exit 1
+fi
+
+IN="${1}/psu_init_gpl.c"
+OUT="${2}/psu_init_gpl.c"
+TMP=$(mktemp /tmp/psu_init_gpl.XX)
+trap "rm ${TMP}" ERR
+
+# Step through a temp file to allow both $IN!=$OUT and $IN==$OUT
+sed -e '/sleep.h/d' \
+-e '/xil_io.h/d' \
+${IN} >${TMP}
+cp ${TMP} ${OUT}
+
+# preprocess to expand defines, then remove cpp lines starting with '#'
+gcc -I${1} -E ${OUT} -o ${TMP}
+sed '/^#/d' ${TMP} >${OUT}
+
+# Remove trivial code before psu_pll_init_data()
+sed -ni '/psu_pll_init_data/,$p' ${OUT}
+
+# Functions are lowercase in U-Boot, rename them
+sed -i 's/PSU_Mask_Write/psu_mask_write/g' ${OUT}
+sed -i 's/mask_pollOnValue/mask_pollonvalue/g' ${OUT}
+sed -i 's/RegValue/regvalue/g' ${OUT}
+sed -i 's/MaskStatus/maskstatus/g' ${OUT}
+
+sed -i '/&= psu_peripherals_powerdwn_data()/d' ${OUT}
+
+FUNCS_TO_REMOVE="psu_protection
+psu_..._protection
+psu_init_xppu_aper_ram
+mask_delay(u32
+mask_read(u32
+dpll_prog
+mask_poll(u32
+mask_pollonvalue(u32
+psu_ps_pl_reset_config_data
+psu_ps_pl_isolation_removal_data
+psu_apply_master_tz
+psu_post_config_data
+psu_post_config_data
+psu_peripherals_powerdwn_data
+psu_init_ddr_self_refresh
+xmpu
+xppu
+"
+for i in $FUNCS_TO_REMOVE; do
+sed -i "/$i/,/^}$/d" ${OUT}
+done
+
+scripts/Lindent ${OUT}
+
+# Prepend 'static' to internal functions
+sed -i 's/^.*data(void)$/static &/g' ${OUT}
+sed -i 's/^.*psu_afi_config(void)$/static &/g' ${OUT}
+sed -i 's/^void init_peripheral/static &/g' ${OUT}
+sed -i 's/^int serdes/static &/g' ${OUT}
+sed -i 's/^int init_serdes/static &/g' ${OUT}
+sed -i 's/^unsigned long /static &/g' ${OUT}
+
+sed -i 's/()$/(void)/g' ${OUT}
+sed -i 's/0X/0x/g' ${OUT}
+
+# Add header
+cat << EOF >${TMP}
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+EOF
+
+cat ${OUT} >>${TMP}
+cp ${TMP} ${OUT}
+
+# Temporarily convert newlines to do some mangling across lines
+tr "\n" "\r" <${OUT} >${TMP}
+
+# Cleanup empty loops. E.g.:
+# |while (e) {|
+# | | ==> |while (e)|
+# |} | |;|
+# | |
+sed -i -r 's| \{\r+(\t*)\}\r\r|\n\1\t;\n|g' ${TMP}
+
+# Remove empty line between variable declaration
+sed -i -r 's|\r(\r\t(unsigned )?int )|\1|g' ${TMP}
+
+# Remove empty lines at function beginning/end
+sed -i -e 's|\r{\r\r|\r{\r|g' ${TMP}
+sed -i -e 's|\r\r}\r|\r}\r|g' ${TMP}
+
+# Remove empty lines after '{' line
+sed -i -e 's| {\r\r| {\r|g' ${TMP}
+
+# Remove braces {} around single statement blocks. E.g.:
+# | while (e) { || while (e) |
+# | stg(); | => | stg();|
+# | } |
+sed -i -r 's| \{(\r[^\r]*;)\r\t*\}|\1|g' ${TMP}
+
+# Remove Unnecessary parentheses around 'n_code <= 0x3C' and similar. E.g.:
+# if ((p_code >= 0x26) && ...) -> if (p_code >= 0x26 && ...)
+sed -i -r 's|\((._code .= [x[:xdigit:]]+)\)|\1|g' ${TMP}
+
+# Convert back newlines
+tr "\r" "\n" <${TMP} >${OUT}
+
+rm ${TMP}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Hi,
On 24/05/19 10:01, Michal Simek wrote:
> On 23. 05. 19 15:54, Luca Ceresoli wrote:
>> Hi,
>>
>> On 22/05/19 12:24, Michal Simek wrote:
>>> On 10. 05. 19 10:15, Luca Ceresoli wrote:
>>>> Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
>>>> only publicly-available compatible carrier card. The SoM is based on the EV
>>>> version of the Xilinx ZynqMP SoC+FPGA.
>>>>
>>>> The psu_init_gpl.c file has been generated from the board definition files
>>>> at [0] using Vivado 2018.3. It has then minimized by
>>>> tools/zynqmp_psu_init_minimize.sh and slightly fixed manually.
>>>>
>>>> [0]
>>>> https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
>>>>
>>>> Signed-off-by: Luca Ceresoli
>>>>
>>>> ---
>>>>
>>>> Whole patchset tested on:
>>>> - current u-boot/master, as is
>>>> - current u-boot-microblaze/master
>>>> - current u-boot-microblaze/master with the addtion of
>>>>commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
>>
>> [...]
>>
>>>> diff --git a/arch/arm/dts/avnet-ultrazedev.dts
>>>> b/arch/arm/dts/avnet-ultrazedev.dts
>>>> new file mode 100644
>>>> index ..34d506a28e88
>>>> --- /dev/null
>>>> +++ b/arch/arm/dts/avnet-ultrazedev.dts
>>
>> [...]
>>
>>>> +/* I2C peripherals on carrier card */
>>>
>>> This is the biggest issue I have with this patch. It is SOM which should
>>> be described in separate file and then we have carried board.
>>> That's why please separate DTS file.
>>
>> Absolutely! Will do.
>>
>>>> +_cc {
>>>> + /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROMs with EUI-48 */
>>>> + eeprom: eeprom@51 {
>>>> + compatible = "at,24c02", "i2c-eeprom";
>>>> + reg = <0x51>;
>>>> + };
>>>> +
>>>> + /* Versa Clock 5P49V5935B */
>>>> + vc5: clock-generator@6a {
>>>> + compatible = "idt,5p49v5935";
>>>> + reg = <0x6a>;
>>>> + #clock-cells = <1>;
>>>> + };
>>>> +};
>>>> +
>>>> +/* Ethernet:
>>>> + * - Marvell 88E1512-A0-NNP2I000 PHY on SOM
>>>> + * - RJ-45 on Carrier Card
>>>> + */
>>>
>>> This is interesting.
>>>
>>>> + {
>>>> + status = "okay";
>>>> + phy-mode = "rgmii-id";
>>>> +};
>>
>> Well, the phy-mode is related to the MAC-PHY link, while the existence
>> of a connector is carrier-dependent. So I think the right thing to do
>> here is:
>>
>> In the SOM dtsi:
>>
>> {
>> phy-mode = "rgmii-id";
>> };
>>
>> and in the carrier dts:
>>
>> {
>> status = "okay";
>> };
>>
>> Does it look OK?
>
> I have looked at schematics and SOM dt should have phy-mode , phy
> address + phy flags if any.
> And yes - you can enable status if there is connector on carrier board.
Ok.
> Anyway I forget to mentioned one thing. Are you willing to test this
> board and keep it updated? I don't want to end up in situation where I
> am with microzed and picozed which I am not able to test myself.
I have access to the board on my workplace and I'm OK with testing it at
least once per U-Boot release, and when needed for e.g. changes that
impact multiple boards.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Hi,
On 22/05/19 12:24, Michal Simek wrote:
> On 10. 05. 19 10:15, Luca Ceresoli wrote:
>> Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
>> only publicly-available compatible carrier card. The SoM is based on the EV
>> version of the Xilinx ZynqMP SoC+FPGA.
>>
>> The psu_init_gpl.c file has been generated from the board definition files
>> at [0] using Vivado 2018.3. It has then minimized by
>> tools/zynqmp_psu_init_minimize.sh and slightly fixed manually.
>>
>> [0]
>> https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
>>
>> Signed-off-by: Luca Ceresoli
>>
>> ---
>>
>> Whole patchset tested on:
>> - current u-boot/master, as is
>> - current u-boot-microblaze/master
>> - current u-boot-microblaze/master with the addtion of
>>commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
[...]
>> diff --git a/arch/arm/dts/avnet-ultrazedev.dts
>> b/arch/arm/dts/avnet-ultrazedev.dts
>> new file mode 100644
>> index ..34d506a28e88
>> --- /dev/null
>> +++ b/arch/arm/dts/avnet-ultrazedev.dts
[...]
>> +/* I2C peripherals on carrier card */
>
> This is the biggest issue I have with this patch. It is SOM which should
> be described in separate file and then we have carried board.
> That's why please separate DTS file.
Absolutely! Will do.
>> +_cc {
>> +/* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROMs with EUI-48 */
>> +eeprom: eeprom@51 {
>> +compatible = "at,24c02", "i2c-eeprom";
>> +reg = <0x51>;
>> +};
>> +
>> +/* Versa Clock 5P49V5935B */
>> +vc5: clock-generator@6a {
>> +compatible = "idt,5p49v5935";
>> +reg = <0x6a>;
>> +#clock-cells = <1>;
>> +};
>> +};
>> +
>> +/* Ethernet:
>> + * - Marvell 88E1512-A0-NNP2I000 PHY on SOM
>> + * - RJ-45 on Carrier Card
>> + */
>
> This is interesting.
>
>> + {
>> +status = "okay";
>> +phy-mode = "rgmii-id";
>> +};
Well, the phy-mode is related to the MAC-PHY link, while the existence
of a connector is carrier-dependent. So I think the right thing to do
here is:
In the SOM dtsi:
{
phy-mode = "rgmii-id";
};
and in the carrier dts:
{
status = "okay";
};
Does it look OK?
>> diff --git a/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
>> b/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
>> new file mode 100644
>> index ..44e683dcee3f
>> --- /dev/null
>> +++ b/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
[...]
>> +static int init_serdes(void)
>> +{
>
> I can't see any description for serdes in DT. That's why you can likely
> remove the whole this function if you are not using GTs.
I see. Actually the board has USB, but I didn't use it, so it's not in
DT. I'll remove all the serdes code in v2.
>> diff --git a/configs/avnet_ultrazedev_defconfig
>> b/configs/avnet_ultrazedev_defconfig
>> new file mode 100644
>> index ..932be1cfb07a
>> --- /dev/null
>> +++ b/configs/avnet_ultrazedev_defconfig
>> @@ -0,0 +1,64 @@
>> +CONFIG_ARM=y
>> +CONFIG_ARCH_ZYNQMP=y
>> +CONFIG_SYS_TEXT_BASE=0x800
>> +CONFIG_SYS_MALLOC_F_LEN=0x8000
>> +CONFIG_SPL=y
>> +CONFIG_DEBUG_UART_BASE=0xff00
>> +CONFIG_DEBUG_UART_CLOCK=1
>> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
>> +CONFIG_SPL_SPI_SUPPORT=y
>> +CONFIG_SPL_ZYNQMP_TWO_SDHCI=y
>> +CONFIG_DEBUG_UART=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> +CONFIG_FIT=y
>> +CONFIG_FIT_VERBOSE=y
>> +CONFIG_SPL_LOAD_FIT=y
>> +CONFIG_BOOTDELAY=0
>> +# CONFIG_DISPLAY_CPUINFO is not set
>> +CONFIG_SPL_TEXT_BASE=0xfffc
>> +CONFIG_SPL_OS_BOOT=y
>> +CONFIG_SYS_PROMPT="ZynqMP> "
>> +CONFIG_CMD_MEMTEST=y
>> +CONFIG_CMD_FPGA_LOADBP=y
>> +CONFIG_CMD_FPGA_LOADP=y
>> +CONFIG_CMD_MMC=y
>> +CONFIG_CMD_SF=y
>> +CONFIG_CMD_SPI=y
>> +CONFIG_CMD_TIME=y
>> +CONFIG_CMD_TIMER=y
>> +CONFIG_CMD_EXT4_WRITE=y
>> +CONFIG_SPL_OF_CONTROL=y
>> +CONFIG_DEFAULT_DEVICE_TREE="avnet-ultrazedev"
>> +CONFIG_NET_RANDOM_ETHADDR=y
>> +CONFIG_SPL_DM=y
>> +CONFIG_SPL_DM_SEQ_ALIAS=y
>> +CONFIG_CLK_ZYNQMP=y
>> +CONFIG_FPGA_XILINX=y
>> +CONFIG_FPGA_ZYNQMPPL=y
>> +CONFIG_DM_GPIO=y
>> +CONFIG_DM_I2C=y
>> +CONFIG_SYS_I2C_CADENCE=y
>> +CONFIG_I2C_MUX=y
>> +CONFIG_I
Re: [U-Boot] [PATCH 2/3] arm64: zynqmp: add tool to minimize psu_init_gpl.c files
Hi,
On 22/05/19 13:11, Michal Simek wrote:
> On 10. 05. 19 10:15, Luca Ceresoli wrote:
>> This script transforms a pair of psu_init_gpl.c and .h files produced by
>> the Xilinx Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that
>> is checkpatch compliant.
>>
>> Based on a script by Michal Simek.
>>
>> Signed-off-by: Luca Ceresoli
>> ---
>> tools/zynqmp_psu_init_minimize.sh | 129 ++
>> 1 file changed, 129 insertions(+)
>> create mode 100755 tools/zynqmp_psu_init_minimize.sh
>>
>> diff --git a/tools/zynqmp_psu_init_minimize.sh
>> b/tools/zynqmp_psu_init_minimize.sh
>> new file mode 100755
>> index ..932426348df4
>> --- /dev/null
>> +++ b/tools/zynqmp_psu_init_minimize.sh
>> @@ -0,0 +1,129 @@
>> +#!/bin/bash
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (C) 2018 Michal Simek
>> +# Copyright (C) 2019 Luca Ceresoli
>> +
>> +# Transform a pair of psu_init_gpl.c and .h files produced by the Xilinx
>> +# Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that is almost
>> +# checkpatch compliant. Minor coding style might still be needed. Must be
>> +# run from the top-level U-Boot source directory.
>> +#
>> +# Usage: zynqmp_psu_init_minimize.sh INPUT_DIR OUTPUT_DIR
>> +# Example: zynqmp_psu_init_minimize.sh \
>> +# /path/to/original/psu_init_gpl_c_and_h/ \
>> +# board/xilinx/zynqmp//
>> +# Note:INPUT_DIR must contain both .c and .h files
>> +
>> +set -o errexit -o errtrace
>> +set -o nounset
>> +
>> +IN="${1}/psu_init_gpl.c"
>> +OUT="${2}/psu_init_gpl.c"
>
> Output looks good but there should be a fix when script is called
> without parameters.
Sure. Will be in v2.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm64: zynqmp: xil_io.h: declare functions as static
Hi, On 22/05/19 13:26, Michal Simek wrote: > On 10. 05. 19 10:15, Luca Ceresoli wrote: >> Fixes chekcpatch warnings when building zynqmp defconfigs: > > it is not checkpatch who reports this. It is sparse. Good catch, will fix. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary
The recently-added ZYNQMP_SPL_PM_CFG_OBJ_FILE option allows SPL to load a
PMUFW configuration object from a binary blob. However the configuration
object is produced by Xilinx proprietary tools as a C source file and no
tool exists to easily convert it to a binary blob in an embedded Linux
build system for U-Boot to use.
Add a simple Python script to do the conversion.
It is definitely not a complete C language parser, but it is enough to
parse the known patterns generated by Xilinx tools, including:
- defines
- literal integers, optionally with a 'U' suffix
- bitwise OR between them
Signed-off-by: Luca Ceresoli
---
Changes v4 -> v5:
- remove argparse allow_abbrev to run on Python < 3.5, Ubuntu 14.04
(Michal)
Changes v3 -> v4:
- move to tools/ directory
- remove double item.strip() call
---
tools/zynqmp_pm_cfg_obj_convert.py | 301 +
1 file changed, 301 insertions(+)
create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py
diff --git a/tools/zynqmp_pm_cfg_obj_convert.py
b/tools/zynqmp_pm_cfg_obj_convert.py
new file mode 100755
index ..dd27f4792131
--- /dev/null
+++ b/tools/zynqmp_pm_cfg_obj_convert.py
@@ -0,0 +1,301 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Luca Ceresoli
+
+import sys
+import re
+import struct
+import logging
+import argparse
+
+parser = argparse.ArgumentParser(
+description='Convert a PMU configuration object from C source to a binary
blob.')
+parser.add_argument('-D', '--debug', action="store_true")
+parser.add_argument(
+"in_file", metavar='INPUT_FILE',
+help='PMU configuration object (C source as produced by Xilinx XSDK)')
+parser.add_argument(
+"out_file", metavar='OUTPUT_FILE',
+help='PMU configuration object binary blob')
+args = parser.parse_args()
+
+logging.basicConfig(format='%(levelname)s:%(message)s',
+level=(logging.DEBUG if args.debug else logging.WARNING))
+
+pm_define = {
+'PM_CAP_ACCESS' : 0x1,
+'PM_CAP_CONTEXT' : 0x2,
+'PM_CAP_WAKEUP' : 0x4,
+
+'NODE_UNKNOWN': 0,
+'NODE_APU': 1,
+'NODE_APU_0' : 2,
+'NODE_APU_1' : 3,
+'NODE_APU_2' : 4,
+'NODE_APU_3' : 5,
+'NODE_RPU': 6,
+'NODE_RPU_0' : 7,
+'NODE_RPU_1' : 8,
+'NODE_PLD': 9,
+'NODE_FPD': 10,
+'NODE_OCM_BANK_0' : 11,
+'NODE_OCM_BANK_1' : 12,
+'NODE_OCM_BANK_2' : 13,
+'NODE_OCM_BANK_3' : 14,
+'NODE_TCM_0_A': 15,
+'NODE_TCM_0_B': 16,
+'NODE_TCM_1_A': 17,
+'NODE_TCM_1_B': 18,
+'NODE_L2' : 19,
+'NODE_GPU_PP_0' : 20,
+'NODE_GPU_PP_1' : 21,
+'NODE_USB_0' : 22,
+'NODE_USB_1' : 23,
+'NODE_TTC_0' : 24,
+'NODE_TTC_1' : 25,
+'NODE_TTC_2' : 26,
+'NODE_TTC_3' : 27,
+'NODE_SATA' : 28,
+'NODE_ETH_0' : 29,
+'NODE_ETH_1' : 30,
+'NODE_ETH_2' : 31,
+'NODE_ETH_3' : 32,
+'NODE_UART_0' : 33,
+'NODE_UART_1' : 34,
+'NODE_SPI_0' : 35,
+'NODE_SPI_1' : 36,
+'NODE_I2C_0' : 37,
+'NODE_I2C_1' : 38,
+'NODE_SD_0' : 39,
+'NODE_SD_1' : 40,
+'NODE_DP' : 41,
+'NODE_GDMA' : 42,
+'NODE_ADMA' : 43,
+'NODE_NAND' : 44,
+'NODE_QSPI' : 45,
+'NODE_GPIO' : 46,
+'NODE_CAN_0' : 47,
+'NODE_CAN_1' : 48,
+'NODE_EXTERN' : 49,
+'NODE_APLL' : 50,
+'NODE_VPLL' : 51,
+'NODE_DPLL' : 52,
+'NODE_RPLL' : 53,
+'NODE_IOPLL' : 54,
+'NODE_DDR': 55,
+'NODE_IPI_APU': 56,
+'NODE_IPI_RPU_0' : 57,
+'NODE_GPU': 58,
+'NODE_PCIE' : 59,
+'NODE_PCAP' : 60,
+'NODE_RTC': 61,
+'NODE_LPD': 62,
+'NODE_VCU': 63,
+'NODE_IPI_RPU_1' : 64,
+'NODE_IPI_PL_0' : 65,
+'NODE_IPI_PL_1' : 66,
+'NODE_IPI_PL_2' : 67,
+'NODE_IPI_PL_3' : 68,
+'NODE_PL' : 69,
+'NODE_ID_MA' : 70,
+
+'XILPM_RESET_PCIE_CFG' : 1000,
+'XILPM_RESET_PCIE_BRIDGE' : 1001,
+'XILPM_RESET_PCIE_CTRL': 1002,
+'XILPM_RESET_DP' : 1003,
+'XILPM_RESET_SWDT_CRF' : 1004,
+'XILPM_RESET_AFI_FM5' : 1005,
+'XILPM_RESET_AFI_FM4' : 1006,
+'XILPM_RESET_AFI_FM3' : 1007,
+'XILPM_RESET_AFI_FM2' : 1008,
+'XILPM_RESET_AFI_FM1' : 1009,
+'XILPM_RESET_AFI_FM0' : 1010,
+'XILPM_RESET_GDMA' : 1011,
+'XILPM_RESET_GPU_PP1' : 1012,
+'XILPM_RESET_GPU_PP0' : 1013,
+'XILPM_RESET_GPU' : 1014,
+'XILPM_RESET_GT' : 1015,
+'XILPM_RESET_SATA' : 1016,
+'XILPM_RESET_ACPU3_PWRON' : 1017,
+
[U-Boot] [PATCH v5 0/2] arm64: zynqmp: pass a PMUFW config object
Hi, here's a minor improvement to 2/2 over v4. 1/1 is unchanged. This patchset aims at solving a long-standing issue in the ZynqMP users community: loading a PMU firmware configuration object when U-Boot SPL is used. The Platform Management Unit (PMU) needs a configuration object (cfg obj) to know how to operate the SoC. When using the "Xilinx workflow", the Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot proper. This is just not implemented in the U-Boot code. The best workaround for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj built-in and self-load it. This approach has some drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuation. It also makes it impossible to change the configuration after boot. The first patch fills the gap by allowing U-Boot SPL to load the cfg obj firmware at runtime. It adds a Kconfig string option to point to the cfg obj in the form of a binary blob. If the option is non-empty, code is enabled to link that file in U-Boot SPL and send the configuration to PMUFW. Patch 2 adds a tool to convert the cfg obj C file (as produced by the Xilinx XSDK proprietary tool) in a binary blob suitable for loading. As suggested by Mike Looijmans it has been implemented as a Python script to make it easily usable. These patches are tested on the UltraZed EV board, on u-boot/master and microblaze/master, using the defconfig I submitted a few days ago [1]. Future work on this topic include moving the PMU IPC code to a mailbox uclass driver and adding a command in U-Boot proper to load a config object blob (e.g. from a file based on a script). Many thanks to Michal Simek for his many suggestions on how to improve this work. [0] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch [1] https://lists.denx.de/pipermail/u-boot/2019-May/368957.html RFCv1: https://lists.denx.de/pipermail/u-boot/2019-February/360450.html RFCv2: https://lists.denx.de/pipermail/u-boot/2019-March/362464.html v3: https://lists.denx.de/pipermail/u-boot/2019-April/365410.html v4: https://lists.denx.de/pipermail/u-boot/2019-May/369427.html Luca Luca Ceresoli (2): arm64: zynqmp: spl: install a PMU firmware config object at runtime arm64: zynqmp: add tool to convert PMU config object .c to binary arch/arm/mach-zynqmp/Kconfig | 18 ++ arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 + arch/arm/mach-zynqmp/pmu_ipc.c| 112 +++ board/xilinx/zynqmp/Makefile | 5 + board/xilinx/zynqmp/pm_cfg_obj.S | 17 + board/xilinx/zynqmp/pm_cfg_obj.h | 9 + board/xilinx/zynqmp/zynqmp.c | 9 + tools/zynqmp_pm_cfg_obj_convert.py| 301 ++ 9 files changed, 477 insertions(+) create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Optionally allow U-Boot to load a configuration object into the Power Management Unit (PMU) firmware on Xilinx ZynqMP. The configuration object is required by the PMU FW to enable most SoC peripherals. So far the only way to boot using U-Boot SPL was to hard-code the configuration object in the PMU firmware. Allow a different boot process, where the PMU FW is equal for any ZynqMP chip and its configuration is passed at runtime by U-Boot SPL. All the code for Inter-processor communication with the PMU is isolated in a new file (pmu_ipc.c). The code is inspired by the same feature as implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted Firmware: * https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295 * https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357 SPL logs on the console before loading the configuration object: U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200) Loading PMUFW cfg obj (2008 bytes) EL Level: EL3 ... Signed-off-by: Luca Ceresoli --- Changes v4 -> v5: none Changes v3 -> v4: - fix pointer-to-integer typecast warning - fix integer-to-pointer typecast warning with proper typecasting and add parentheses to avoid ambiguity - fix kerneldoc syntax (Michal) - remove empty line in Kconfig (Michal) - remove #ifdefs around function declaration (Michal) - remove unneeded file copy (Michal) - move externs to a new .h file (Michal) - avoid passing the extra -DZYNQMP_LOAD_PM_CFG_OBJ (using sizeof(), it looks a bit of a hack but seems to be working) - rename CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE to CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE and clarify in menuconfig that it's SPL-related Changes RFC v2 -> v3: - don't compile pm_cfg_obj.c from source, load it from a binary file (suggested by Michal) - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal) Changes RFC v1 -> RFC v2: - Load the cfg_obj in SPL, not U-Boot proper: this required a complete reimplementation since we cannot rely on ATF now - Update and refine the Kconfig option help --- arch/arm/mach-zynqmp/Kconfig | 18 +++ arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 + arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++ board/xilinx/zynqmp/Makefile | 5 + board/xilinx/zynqmp/pm_cfg_obj.S | 17 +++ board/xilinx/zynqmp/pm_cfg_obj.h | 9 ++ board/xilinx/zynqmp/zynqmp.c | 9 ++ 8 files changed, 176 insertions(+) create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig index 9bb5a5c20201..6cf17eb94e11 100644 --- a/arch/arm/mach-zynqmp/Kconfig +++ b/arch/arm/mach-zynqmp/Kconfig @@ -65,6 +65,24 @@ config PMUFW_INIT_FILE Include external PMUFW (Platform Management Unit FirmWare) to a Xilinx bootable image (boot.bin). +config ZYNQMP_SPL_PM_CFG_OBJ_FILE + string "PMU firmware configuration object to load at runtime by SPL" + depends on SPL + help + Path to a binary PMU firmware configuration object to be linked + into U-Boot SPL and loaded at runtime into the PMU firmware. + + The ZynqMP Power Management Unit (PMU) needs a configuration + object for most SoC peripherals to work. To have it loaded by + U-Boot SPL set here the file name (absolute path or relative to + the top source tree) of your configuration, which must be a + binary blob. It will be linked in the SPL binary and loaded + into the PMU firmware by U-Boot SPL during board + initialization. + + Leave this option empty if your PMU firmware has a hard-coded + configuration object or you are loading it by any other means. + config ZYNQMP_USB bool "Configure ZynqMP USB" diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile index 8a3b0747244a..f3765e45b1b9 100644 --- a/arch/arm/mach-zynqmp/Makefile +++ b/arch/arm/mach-zynqmp/Makefile @@ -8,3 +8,7 @@ obj-y += cpu.o obj-$(CONFIG_MP) += mp.o obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED) += psu_spl_init.o + +ifneq ($(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE),"") +obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o +endif diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h b/arch/arm/mach-zynqmp/include/mach/sys_proto.h index 385c8825f2f6..915badc6fbee 100644 --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h @@ -72,4 +72,6 @@ int chip_id(unsigned char id)
[U-Boot] [PATCH v4 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary
The recently-added ZYNQMP_SPL_PM_CFG_OBJ_FILE option allows SPL to load a
PMUFW configuration object from a binary blob. However the configuration
object is produced by Xilinx proprietary tools as a C source file and no
tool exists to easily convert it to a binary blob in an embedded Linux
build system for U-Boot to use.
Add a simple Python script to do the conversion.
It is definitely not a complete C language parser, but it is enough to
parse the known patterns generated by Xilinx tools, including:
- defines
- literal integers, optionally with a 'U' suffix
- bitwise OR between them
Signed-off-by: Luca Ceresoli
---
Changes v3 -> v4:
- move to tools/ directory
- remove double item.strip() call
---
tools/zynqmp_pm_cfg_obj_convert.py | 302 +
1 file changed, 302 insertions(+)
create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py
diff --git a/tools/zynqmp_pm_cfg_obj_convert.py
b/tools/zynqmp_pm_cfg_obj_convert.py
new file mode 100755
index ..bb4959877df7
--- /dev/null
+++ b/tools/zynqmp_pm_cfg_obj_convert.py
@@ -0,0 +1,302 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Luca Ceresoli
+
+import sys
+import re
+import struct
+import logging
+import argparse
+
+parser = argparse.ArgumentParser(
+description='Convert a PMU configuration object from C source to a binary
blob.',
+allow_abbrev=False)
+parser.add_argument('-D', '--debug', action="store_true")
+parser.add_argument(
+"in_file", metavar='INPUT_FILE',
+help='PMU configuration object (C source as produced by Xilinx XSDK)')
+parser.add_argument(
+"out_file", metavar='OUTPUT_FILE',
+help='PMU configuration object binary blob')
+args = parser.parse_args()
+
+logging.basicConfig(format='%(levelname)s:%(message)s',
+level=(logging.DEBUG if args.debug else logging.WARNING))
+
+pm_define = {
+'PM_CAP_ACCESS' : 0x1,
+'PM_CAP_CONTEXT' : 0x2,
+'PM_CAP_WAKEUP' : 0x4,
+
+'NODE_UNKNOWN': 0,
+'NODE_APU': 1,
+'NODE_APU_0' : 2,
+'NODE_APU_1' : 3,
+'NODE_APU_2' : 4,
+'NODE_APU_3' : 5,
+'NODE_RPU': 6,
+'NODE_RPU_0' : 7,
+'NODE_RPU_1' : 8,
+'NODE_PLD': 9,
+'NODE_FPD': 10,
+'NODE_OCM_BANK_0' : 11,
+'NODE_OCM_BANK_1' : 12,
+'NODE_OCM_BANK_2' : 13,
+'NODE_OCM_BANK_3' : 14,
+'NODE_TCM_0_A': 15,
+'NODE_TCM_0_B': 16,
+'NODE_TCM_1_A': 17,
+'NODE_TCM_1_B': 18,
+'NODE_L2' : 19,
+'NODE_GPU_PP_0' : 20,
+'NODE_GPU_PP_1' : 21,
+'NODE_USB_0' : 22,
+'NODE_USB_1' : 23,
+'NODE_TTC_0' : 24,
+'NODE_TTC_1' : 25,
+'NODE_TTC_2' : 26,
+'NODE_TTC_3' : 27,
+'NODE_SATA' : 28,
+'NODE_ETH_0' : 29,
+'NODE_ETH_1' : 30,
+'NODE_ETH_2' : 31,
+'NODE_ETH_3' : 32,
+'NODE_UART_0' : 33,
+'NODE_UART_1' : 34,
+'NODE_SPI_0' : 35,
+'NODE_SPI_1' : 36,
+'NODE_I2C_0' : 37,
+'NODE_I2C_1' : 38,
+'NODE_SD_0' : 39,
+'NODE_SD_1' : 40,
+'NODE_DP' : 41,
+'NODE_GDMA' : 42,
+'NODE_ADMA' : 43,
+'NODE_NAND' : 44,
+'NODE_QSPI' : 45,
+'NODE_GPIO' : 46,
+'NODE_CAN_0' : 47,
+'NODE_CAN_1' : 48,
+'NODE_EXTERN' : 49,
+'NODE_APLL' : 50,
+'NODE_VPLL' : 51,
+'NODE_DPLL' : 52,
+'NODE_RPLL' : 53,
+'NODE_IOPLL' : 54,
+'NODE_DDR': 55,
+'NODE_IPI_APU': 56,
+'NODE_IPI_RPU_0' : 57,
+'NODE_GPU': 58,
+'NODE_PCIE' : 59,
+'NODE_PCAP' : 60,
+'NODE_RTC': 61,
+'NODE_LPD': 62,
+'NODE_VCU': 63,
+'NODE_IPI_RPU_1' : 64,
+'NODE_IPI_PL_0' : 65,
+'NODE_IPI_PL_1' : 66,
+'NODE_IPI_PL_2' : 67,
+'NODE_IPI_PL_3' : 68,
+'NODE_PL' : 69,
+'NODE_ID_MA' : 70,
+
+'XILPM_RESET_PCIE_CFG' : 1000,
+'XILPM_RESET_PCIE_BRIDGE' : 1001,
+'XILPM_RESET_PCIE_CTRL': 1002,
+'XILPM_RESET_DP' : 1003,
+'XILPM_RESET_SWDT_CRF' : 1004,
+'XILPM_RESET_AFI_FM5' : 1005,
+'XILPM_RESET_AFI_FM4' : 1006,
+'XILPM_RESET_AFI_FM3' : 1007,
+'XILPM_RESET_AFI_FM2' : 1008,
+'XILPM_RESET_AFI_FM1' : 1009,
+'XILPM_RESET_AFI_FM0' : 1010,
+'XILPM_RESET_GDMA' : 1011,
+'XILPM_RESET_GPU_PP1' : 1012,
+'XILPM_RESET_GPU_PP0' : 1013,
+'XILPM_RESET_GPU' : 1014,
+'XILPM_RESET_GT' : 1015,
+'XILPM_RESET_SATA' : 1016,
+'XILPM_RESET_ACPU3_PWRON' : 1017,
+'XILPM_RESET_ACPU2_PWRON' : 1018,
+'XILPM_RESET_ACPU1_PWRON' : 1019,
+'XIL
[U-Boot] [PATCH v4 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Optionally allow U-Boot to load a configuration object into the Power Management Unit (PMU) firmware on Xilinx ZynqMP. The configuration object is required by the PMU FW to enable most SoC peripherals. So far the only way to boot using U-Boot SPL was to hard-code the configuration object in the PMU firmware. Allow a different boot process, where the PMU FW is equal for any ZynqMP chip and its configuration is passed at runtime by U-Boot SPL. All the code for Inter-processor communication with the PMU is isolated in a new file (pmu_ipc.c). The code is inspired by the same feature as implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted Firmware: * https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295 * https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357 SPL logs on the console before loading the configuration object: U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200) Loading PMUFW cfg obj (2008 bytes) EL Level: EL3 ... Signed-off-by: Luca Ceresoli --- Changes v3 -> v4: - fix pointer-to-integer typecast warning - fix integer-to-pointer typecast warning with proper typecasting and add parentheses to avoid ambiguity - fix kerneldoc syntax (Michal) - remove empty line in Kconfig (Michal) - remove #ifdefs around function declaration (Michal) - remove unneeded file copy (Michal) - move externs to a new .h file (Michal) - avoid passing the extra -DZYNQMP_LOAD_PM_CFG_OBJ (using sizeof(), it looks a bit of a hack but seems to be working) - rename CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE to CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE and clarify in menuconfig that it's SPL-related Changes RFC v2 -> v3: - don't compile pm_cfg_obj.c from source, load it from a binary file (suggested by Michal) - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal) Changes RFC v1 -> RFC v2: - Load the cfg_obj in SPL, not U-Boot proper: this required a complete reimplementation since we cannot rely on ATF now - Update and refine the Kconfig option help --- arch/arm/mach-zynqmp/Kconfig | 18 +++ arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 + arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++ board/xilinx/zynqmp/Makefile | 5 + board/xilinx/zynqmp/pm_cfg_obj.S | 17 +++ board/xilinx/zynqmp/pm_cfg_obj.h | 9 ++ board/xilinx/zynqmp/zynqmp.c | 9 ++ 8 files changed, 176 insertions(+) create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig index 9bb5a5c20201..6cf17eb94e11 100644 --- a/arch/arm/mach-zynqmp/Kconfig +++ b/arch/arm/mach-zynqmp/Kconfig @@ -65,6 +65,24 @@ config PMUFW_INIT_FILE Include external PMUFW (Platform Management Unit FirmWare) to a Xilinx bootable image (boot.bin). +config ZYNQMP_SPL_PM_CFG_OBJ_FILE + string "PMU firmware configuration object to load at runtime by SPL" + depends on SPL + help + Path to a binary PMU firmware configuration object to be linked + into U-Boot SPL and loaded at runtime into the PMU firmware. + + The ZynqMP Power Management Unit (PMU) needs a configuration + object for most SoC peripherals to work. To have it loaded by + U-Boot SPL set here the file name (absolute path or relative to + the top source tree) of your configuration, which must be a + binary blob. It will be linked in the SPL binary and loaded + into the PMU firmware by U-Boot SPL during board + initialization. + + Leave this option empty if your PMU firmware has a hard-coded + configuration object or you are loading it by any other means. + config ZYNQMP_USB bool "Configure ZynqMP USB" diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile index 8a3b0747244a..f3765e45b1b9 100644 --- a/arch/arm/mach-zynqmp/Makefile +++ b/arch/arm/mach-zynqmp/Makefile @@ -8,3 +8,7 @@ obj-y += cpu.o obj-$(CONFIG_MP) += mp.o obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED) += psu_spl_init.o + +ifneq ($(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE),"") +obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o +endif diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h b/arch/arm/mach-zynqmp/include/mach/sys_proto.h index 385c8825f2f6..915badc6fbee 100644 --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h @@ -72,4 +72,6 @@ int chip_id(unsigned char id);
[U-Boot] [PATCH v4 0/2] arm64: zynqmp: pass a PMUFW config object
Hi, this v4 has several small improvements over v3, addressing all the comments received. No major changes. This patchset aims at solving a long-standing issue in the ZynqMP users community: loading a PMU firmware configuration object when U-Boot SPL is used. The Platform Management Unit (PMU) needs a configuration object (cfg obj) to know how to operate the SoC. When using the "Xilinx workflow", the Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot proper. This is just not implemented in the U-Boot code. The best workaround for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj built-in and self-load it. This approach has some drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuation. It also makes it impossible to change the configuration after boot. The first patch fills the gap by allowing U-Boot SPL to load the cfg obj firmware at runtime. It adds a Kconfig string option to point to the cfg obj in the form of a binary blob. If the option is non-empty, code is enabled to link that file in U-Boot SPL and send the configuration to PMUFW. Patch 2 adds a tool to convert the cfg obj C file (as produced by the Xilinx XSDK proprietary tool) in a binary blob suitable for loading. As suggested by Mike Looijmans it has been implemented as a Python script to make it easily usable. These patches are tested on the UltraZed EV board, on u-boot/master and microblaze/master, using the defconfig I submitted a few days ago [1]. Future work on this topic include moving the PMU IPC code to a mailbox uclass driver and adding a command in U-Boot proper to load a config object blob (e.g. from a file based on a script). Many thanks to Michal Simek for his many suggestions on how to improve this work. [0] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch [1] https://lists.denx.de/pipermail/u-boot/2019-May/368957.html RFCv1: https://lists.denx.de/pipermail/u-boot/2019-February/360450.html RFCv2: https://lists.denx.de/pipermail/u-boot/2019-March/362464.html v3: https://lists.denx.de/pipermail/u-boot/2019-April/365410.html Luca Luca Ceresoli (2): arm64: zynqmp: spl: install a PMU firmware config object at runtime arm64: zynqmp: add tool to convert PMU config object .c to binary arch/arm/mach-zynqmp/Kconfig | 18 ++ arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 + arch/arm/mach-zynqmp/pmu_ipc.c| 112 +++ board/xilinx/zynqmp/Makefile | 5 + board/xilinx/zynqmp/pm_cfg_obj.S | 17 + board/xilinx/zynqmp/pm_cfg_obj.h | 9 + board/xilinx/zynqmp/zynqmp.c | 9 + tools/zynqmp_pm_cfg_obj_convert.py| 302 ++ 9 files changed, 478 insertions(+) create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.h create mode 100755 tools/zynqmp_pm_cfg_obj_convert.py -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi, On 14/05/19 17:45, Michal Simek wrote: >>> +$(obj)/pm_cfg_obj.o: $(obj)/pm_cfg_obj.bin >>> + >>> +CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ >> >> I am no fan of passing another object. you have >> CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE already and this can be used instead. > > Not sure I got your point here. I'm not passing an object, just setting > a define (without value). This is used to enable code under #ifdef in C > files. Sorry I meant new config option. It should be enough to use CFG_OBJ_FILE everywhere and not create another config option which is just used the same way. >>> >>> I totally agree. But I would need to check whether >>> CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE is empty or not, and I don't think >>> the C preprocessor can do that. >> >> Any news on this issue? It's the only issue still open on this series, >> and as said, I don't think there's a way to avoid the extra define. As >> such, unless a smart solution emerges suddenly, I'm sending v4 in one or >> two days with all the other issues fixed. > > I didn't spend any time on this. Try to grep it. If you don't file > anything please add there TODO and let's fix it in future. I did grep and searched, but the core problem is that the preprocessor cannot compare strings. But now I found a way out. Looks a bit of a hack to me, but it works, will be in v4. If that's not OK, I'll do v5 with the current solution and a TODO. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi Michal, All, On 07/05/19 16:11, Luca Ceresoli wrote: > Hi, > > On 06/05/19 17:56, Michal Simek wrote: >> Hi, >> >> snip. >> >>>>> +$(obj)/pm_cfg_obj.o: $(obj)/pm_cfg_obj.bin >>>>> + >>>>> +CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ >>>> >>>> I am no fan of passing another object. you have >>>> CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE already and this can be used instead. >>> >>> Not sure I got your point here. I'm not passing an object, just setting >>> a define (without value). This is used to enable code under #ifdef in C >>> files. >> >> Sorry I meant new config option. It should be enough to use CFG_OBJ_FILE >> everywhere and not create another config option which is just used the >> same way. > > I totally agree. But I would need to check whether > CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE is empty or not, and I don't think > the C preprocessor can do that. Any news on this issue? It's the only issue still open on this series, and as said, I don't think there's a way to avoid the extra define. As such, unless a smart solution emerges suddenly, I'm sending v4 in one or two days with all the other issues fixed. Thanks, -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
only publicly-available compatible carrier card. The SoM is based on the EV
version of the Xilinx ZynqMP SoC+FPGA.
The psu_init_gpl.c file has been generated from the board definition files
at [0] using Vivado 2018.3. It has then minimized by
tools/zynqmp_psu_init_minimize.sh and slightly fixed manually.
[0]
https://github.com/Avnet/bdf/tree/3686c9ff7d2f0467fb4fcf39f861b8d6ff183b12/ultrazed_7ev_cc/1.1
Signed-off-by: Luca Ceresoli
---
Whole patchset tested on:
- current u-boot/master, as is
- current u-boot-microblaze/master
- current u-boot-microblaze/master with the addtion of
commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/avnet-ultrazedev.dts | 90 ++
.../zynqmp/avnet-ultrazedev/psu_init_gpl.c| 1029 +
configs/avnet_ultrazedev_defconfig| 64 +
4 files changed, 1184 insertions(+)
create mode 100644 arch/arm/dts/avnet-ultrazedev.dts
create mode 100644 board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
create mode 100644 configs/avnet_ultrazedev_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8167cdb4e856..f22fade35a66 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zybo-z7.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
+ avnet-ultrazedev.dtb\
zynqmp-mini.dtb \
zynqmp-mini-emmc0.dtb \
zynqmp-mini-emmc1.dtb \
diff --git a/arch/arm/dts/avnet-ultrazedev.dts
b/arch/arm/dts/avnet-ultrazedev.dts
new file mode 100644
index ..34d506a28e88
--- /dev/null
+++ b/arch/arm/dts/avnet-ultrazedev.dts
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/dts-v1/;
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>, /* 2 GB @ offset 0 */
+ <0x8 0x0 0x0 0x8000>; /* 2 GB @ offset 32GB */
+ };
+ chosen {
+ stdout-path = "serial0:115200n8";
+ xlnx,eeprom =
+ };
+ aliases {
+ ethernet0 =
+ serial0 =
+ };
+};
+
+ {
+ device_type = "serial";
+ port-number = <0>;
+ status = "okay";
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ clock-frequency = <40>;
+ status = "okay";
+
+ i2cswitch@70 {
+ compatible = "nxp,pca9543";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ /* I2C connected to Carrier Card via JX3A1/JX3C1 */
+ i2c_cc: i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+/* I2C peripherals on carrier card */
+_cc {
+ /* Microchip 24AA025E48T-I/OT: 2K I2C Serial EEPROMs with EUI-48 */
+ eeprom: eeprom@51 {
+ compatible = "at,24c02", "i2c-eeprom";
+ reg = <0x51>;
+ };
+
+ /* Versa Clock 5P49V5935B */
+ vc5: clock-generator@6a {
+ compatible = "idt,5p49v5935";
+ reg = <0x6a>;
+ #clock-cells = <1>;
+ };
+};
+
+/* Ethernet:
+ * - Marvell 88E1512-A0-NNP2I000 PHY on SOM
+ * - RJ-45 on Carrier Card
+ */
+ {
+ status = "okay";
+ phy-mode = "rgmii-id";
+};
+
+/* eMMC on SoM */
+ {
+ status = "okay";
+ xlnx,mio_bank = <0>;
+ clock-frequency = <18000>;
+};
+
+/* microSD card slot on carrier card */
+ {
+ status = "okay";
+ xlnx,mio_bank = <1>;
+ clock-frequency = <18000>;
+ max-frequency = <5000>;
+ no-1-8-v;
+ disable-wp;
+};
diff --git a/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
b/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
new file mode 100644
index ..44e683dcee3f
--- /dev/null
+++ b/board/xilinx/zynqmp/avnet-ultrazedev/psu_init_gpl.c
@@ -0,0 +1,1029 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+static unsigned long psu_pll_init_data(void)
+{
+ psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4B0C62U);
+ psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00014800U);
+ psu_mask_write(0xFF5E0030, 0x0008U, 0x0008U);
+ psu_mask_write(0xFF5E0030, 0x0001U, 0x0001U);
+
[U-Boot] [PATCH 2/3] arm64: zynqmp: add tool to minimize psu_init_gpl.c files
This script transforms a pair of psu_init_gpl.c and .h files produced by
the Xilinx Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that
is checkpatch compliant.
Based on a script by Michal Simek.
Signed-off-by: Luca Ceresoli
---
tools/zynqmp_psu_init_minimize.sh | 129 ++
1 file changed, 129 insertions(+)
create mode 100755 tools/zynqmp_psu_init_minimize.sh
diff --git a/tools/zynqmp_psu_init_minimize.sh
b/tools/zynqmp_psu_init_minimize.sh
new file mode 100755
index ..932426348df4
--- /dev/null
+++ b/tools/zynqmp_psu_init_minimize.sh
@@ -0,0 +1,129 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2018 Michal Simek
+# Copyright (C) 2019 Luca Ceresoli
+
+# Transform a pair of psu_init_gpl.c and .h files produced by the Xilinx
+# Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that is almost
+# checkpatch compliant. Minor coding style might still be needed. Must be
+# run from the top-level U-Boot source directory.
+#
+# Usage: zynqmp_psu_init_minimize.sh INPUT_DIR OUTPUT_DIR
+# Example: zynqmp_psu_init_minimize.sh \
+# /path/to/original/psu_init_gpl_c_and_h/ \
+# board/xilinx/zynqmp//
+# Note:INPUT_DIR must contain both .c and .h files
+
+set -o errexit -o errtrace
+set -o nounset
+
+IN="${1}/psu_init_gpl.c"
+OUT="${2}/psu_init_gpl.c"
+TMP=$(mktemp /tmp/psu_init_gpl.XX)
+trap "rm ${TMP}" ERR
+
+# Step through a temp file to allow both $IN!=$OUT and $IN==$OUT
+sed -e '/sleep.h/d' \
+-e '/xil_io.h/d' \
+${IN} >${TMP}
+cp ${TMP} ${OUT}
+
+# preprocess to expand defines, then remove cpp lines starting with '#'
+gcc -I${1} -E ${OUT} -o ${TMP}
+sed '/^#/d' ${TMP} >${OUT}
+
+# Remove trivial code before psu_pll_init_data()
+sed -ni '/psu_pll_init_data/,$p' ${OUT}
+
+# Functions are lowercase in U-Boot, rename them
+sed -i 's/PSU_Mask_Write/psu_mask_write/g' ${OUT}
+sed -i 's/mask_pollOnValue/mask_pollonvalue/g' ${OUT}
+sed -i 's/RegValue/regvalue/g' ${OUT}
+sed -i 's/MaskStatus/maskstatus/g' ${OUT}
+
+sed -i '/&= psu_peripherals_powerdwn_data()/d' ${OUT}
+
+FUNCS_TO_REMOVE="psu_protection
+psu_..._protection
+psu_init_xppu_aper_ram
+mask_delay(u32
+mask_read(u32
+dpll_prog
+mask_poll(u32
+mask_pollonvalue(u32
+psu_ps_pl_reset_config_data
+psu_ps_pl_isolation_removal_data
+psu_apply_master_tz
+psu_post_config_data
+psu_post_config_data
+psu_peripherals_powerdwn_data
+psu_init_ddr_self_refresh
+xmpu
+xppu
+"
+for i in $FUNCS_TO_REMOVE; do
+sed -i "/$i/,/^}$/d" ${OUT}
+done
+
+scripts/Lindent ${OUT}
+
+# Prepend 'static' to internal functions
+sed -i 's/^.*data(void)$/static &/g' ${OUT}
+sed -i 's/^.*psu_afi_config(void)$/static &/g' ${OUT}
+sed -i 's/^void init_peripheral/static &/g' ${OUT}
+sed -i 's/^int serdes/static &/g' ${OUT}
+sed -i 's/^int init_serdes/static &/g' ${OUT}
+sed -i 's/^unsigned long /static &/g' ${OUT}
+
+sed -i 's/()$/(void)/g' ${OUT}
+sed -i 's/0X/0x/g' ${OUT}
+
+# Add header
+cat << EOF >${TMP}
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+EOF
+
+cat ${OUT} >>${TMP}
+cp ${TMP} ${OUT}
+
+# Temporarily convert newlines to do some mangling across lines
+tr "\n" "\r" <${OUT} >${TMP}
+
+# Cleanup empty loops. E.g.:
+# |while (e) {|
+# | | ==> |while (e)|
+# |} | |;|
+# | |
+sed -i -r 's| \{\r+(\t*)\}\r\r|\n\1\t;\n|g' ${TMP}
+
+# Remove empty line between variable declaration
+sed -i -r 's|\r(\r\t(unsigned )?int )|\1|g' ${TMP}
+
+# Remove empty lines at function beginning/end
+sed -i -e 's|\r{\r\r|\r{\r|g' ${TMP}
+sed -i -e 's|\r\r}\r|\r}\r|g' ${TMP}
+
+# Remove empty lines after '{' line
+sed -i -e 's| {\r\r| {\r|g' ${TMP}
+
+# Remove braces {} around single statement blocks. E.g.:
+# | while (e) { || while (e) |
+# | stg(); | => | stg();|
+# | } |
+sed -i -r 's| \{(\r[^\r]*;)\r\t*\}|\1|g' ${TMP}
+
+# Remove Unnecessary parentheses around 'n_code <= 0x3C' and similar. E.g.:
+# if ((p_code >= 0x26) && ...) -> if (p_code >= 0x26 && ...)
+sed -i -r 's|\((._code .= [x[:xdigit:]]+)\)|\1|g' ${TMP}
+
+# Convert back newlines
+tr "\r" "\n" <${TMP} >${OUT}
+
+rm ${TMP}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm64: zynqmp: xil_io.h: declare functions as static
Fixes chekcpatch warnings when building zynqmp defconfigs:
./board/xilinx/zynqmp/xil_io.h:12:6: warning: symbol 'Xil_Out32' was not
declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:17:5: warning: symbol 'Xil_In32' was not
declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:22:6: warning: symbol 'usleep' was not
declared. Should it be static?
Also add __maybe_unused to usleep() since it is not used by minimized
psu_init_gpl.c files, so it would warn as "defined but not used".
Signed-off-by: Luca Ceresoli
---
board/xilinx/zynqmp/xil_io.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/zynqmp/xil_io.h b/board/xilinx/zynqmp/xil_io.h
index c476c902ebcb..1c1bf32adaae 100644
--- a/board/xilinx/zynqmp/xil_io.h
+++ b/board/xilinx/zynqmp/xil_io.h
@@ -9,17 +9,17 @@
#define xil_printf(...)
-void Xil_Out32(unsigned long addr, unsigned long val)
+static void Xil_Out32(unsigned long addr, unsigned long val)
{
writel(val, addr);
}
-int Xil_In32(unsigned long addr)
+static int Xil_In32(unsigned long addr)
{
return readl(addr);
}
-void usleep(u32 sleep)
+static void __maybe_unused usleep(u32 sleep)
{
udelay(sleep);
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi,
On 06/05/19 17:56, Michal Simek wrote:
> Hi,
>
> snip.
>
+$(obj)/pm_cfg_obj.o: $(obj)/pm_cfg_obj.bin
+
+CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ
>>>
>>> I am no fan of passing another object. you have
>>> CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE already and this can be used instead.
>>
>> Not sure I got your point here. I'm not passing an object, just setting
>> a define (without value). This is used to enable code under #ifdef in C
>> files.
>
> Sorry I meant new config option. It should be enough to use CFG_OBJ_FILE
> everywhere and not create another config option which is just used the
> same way.
I totally agree. But I would need to check whether
CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE is empty or not, and I don't think
the C preprocessor can do that.
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index db272478506f..7fcb3e120688 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -327,6 +327,14 @@ int board_early_init_f(void)
int board_init(void)
{
+#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ)
+ extern const u32 zynqmp_pm_cfg_obj[];
+ extern const int zynqmp_pm_cfg_obj_size;
>>>
>>> please put these two to header instead.
>>
>> This was done on purpose to reduce the amount of #ifdefs, and also to
>> not pollute the namespace with two symbols that are not needed outside
>> this function. I don't see the added value of moving them in a .h, but I
>> might be wrong.
>
> Is checkpatch ok with this? I think that it should error out that you
> shouldn't put externs to .c files.
Uhm, no, checkpatch is not ok with this. I disagree, but for sake of
peace in the world I'll move it to a .h file.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi Michal, thanks for your review. See my replies below. On 04/05/19 00:38, Michal Simek wrote: > On 15. 04. 19 9:47, Luca Ceresoli wrote: >> Optionally allow U-Boot to load at the PMU firmware configuration object >> into the Power Management Unit (PMU) on Xilinx ZynqMP. >> >> The configuration object is required by the PMU FW to enable most SoC >> peripherals. So far the only way to boot using U-Boot SPL was to hard-code >> the configuration object in the PMU firmware. Allow a different boot >> process, where the PMU FW is equal for any ZynqMP chip and its >> configuration is passed at runtime by U-Boot SPL. >> >> All the code for Inter-processor communication with the PMU is isolated in >> a new file (pmu_ipc.c). The code is inspired by the same feature as >> implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted >> Firmware: >> >> * >> https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295 >> * >> https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357 >> >> SPL logs on the console before loading the configuration object: >> >> U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21) >> Loading PMUFW cfg obj (2008 bytes) >> EL Level: EL3 >> ... >> >> Signed-off-by: Luca Ceresoli >> >> --- >> >> Changes RFC v2 -> v3: >> - don't compile pm_cfg_obj.c from source, load it from a binary file >>(suggested by Michal) >> - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal) >> >> Changes RFC v1 -> RFC v2: >> - Load the cfg_obj in SPL, not U-Boot proper: this required a complete >>reimplementation since we cannot rely on ATF now >> - Update and refine the Kconfig option help >> --- >> arch/arm/mach-zynqmp/Kconfig | 17 +++ >> arch/arm/mach-zynqmp/Makefile | 4 + >> arch/arm/mach-zynqmp/include/mach/sys_proto.h | 4 + >> arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++ >> board/xilinx/zynqmp/Makefile | 12 ++ >> board/xilinx/zynqmp/pm_cfg_obj.S | 17 +++ >> board/xilinx/zynqmp/zynqmp.c | 8 ++ >> 7 files changed, 174 insertions(+) >> create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c >> create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S >> >> diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig >> index 9bb5a5c20201..b88d1d313839 100644 >> --- a/arch/arm/mach-zynqmp/Kconfig >> +++ b/arch/arm/mach-zynqmp/Kconfig >> @@ -65,6 +65,23 @@ config PMUFW_INIT_FILE >>Include external PMUFW (Platform Management Unit FirmWare) to >>a Xilinx bootable image (boot.bin). >> >> +config ZYNQMP_LOAD_PM_CFG_OBJ_FILE >> +string "PMU firmware configuration object to load at runtime" >> +help >> + > > remove this empty line. OK. >> diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h >> b/arch/arm/mach-zynqmp/include/mach/sys_proto.h >> index 385c8825f2f6..e2b9a79ed539 100644 >> --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h >> +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h >> @@ -72,4 +72,8 @@ int chip_id(unsigned char id); >> void tcm_init(u8 mode); >> #endif >> >> +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ) >> +void zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size); >> +#endif > > nit: you can remove that if/endif to open a way to also pass different > configuration object from full u-boot. Good idea. Less #ifdefs is always good as well. >> diff --git a/arch/arm/mach-zynqmp/pmu_ipc.c b/arch/arm/mach-zynqmp/pmu_ipc.c >> new file mode 100644 >> index ..5feb8568f8de >> --- /dev/null >> +++ b/arch/arm/mach-zynqmp/pmu_ipc.c >> @@ -0,0 +1,112 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Inter-Processor Communication with the Platform Management Unit (PMU) >> + * firmware. >> + * >> + * (C) Copyright 2019 Luca Ceresoli >> + * Luca Ceresoli >> + */ >> + >> +#include >> +#include >> +#include >> + >> +/* IPI bitmasks, register base and register offsets */ >> +#define IPI_BIT_MASK_APU 0x1 >> +#define IPI_BIT_MASK_PMU0 0x1 >> +#define IPI_REG_BASE_APU 0xFF30 >> +#define IPI_REG_BASE_PMU0 0xFF33 >> +#define IPI_REG_
Re: [U-Boot] [PATCH v3 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary
Hi Michal,
On 04/05/19 00:31, Michal Simek wrote:
> Hi,
>
> On 15. 04. 19 9:47, Luca Ceresoli wrote:
>> The recently-added ZYNQMP_LOAD_PM_CFG_OBJ_FILE option allows SPL to load a
>> PMUFW configuration object from a binary blob. However the configuration
>> object is produced by Xilinx proprietary tools as a C source file and no
>> tool exists to easily convert it to a binary blob in an embedded Linux
>> build system for U-Boot to use.
>>
>> Add a simple Python script to do the conversion.
>>
>> It is definitely not a complete C language parser, but it is enough to
>> parse the known patterns generated by Xilinx tools, including:
>>
>> - defines
>> - literal integers, optionally with a 'U' suffix
>> - bitwise OR between them
>>
>> Signed-off-by: Luca Ceresoli
>> ---
>> arch/arm/mach-zynqmp/pm_cfg_obj_convert.py | 302 +
>> 1 file changed, 302 insertions(+)
>> create mode 100755 arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>>
>> diff --git a/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>> b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>> new file mode 100755
>> index ..5aea15860319
>> --- /dev/null
>> +++ b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
>> @@ -0,0 +1,302 @@
>> +#!/usr/bin/env python3
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (C) 2019 Luca Ceresoli
>> +
>> +import sys
>> +import re
>> +import struct
>> +import logging
>> +import argparse
>> +
>> +parser = argparse.ArgumentParser(
>> +description='Convert a PMU configuration object from C source to a
>> binary blob.',
>> +allow_abbrev=False)
>> +parser.add_argument('-D', '--debug', action="store_true")
>> +parser.add_argument(
>> +"in_file", metavar='INPUT_FILE',
>> +help='PMU configuration object (C source as produced by Xilinx XSDK)')
>> +parser.add_argument(
>> +"out_file", metavar='OUTPUT_FILE',
>> +help='PMU configuration object binary blob')
>> +args = parser.parse_args()
>> +
>> +logging.basicConfig(format='%(levelname)s:%(message)s',
>> +level=(logging.DEBUG if args.debug else
>> logging.WARNING))
>> +
>> +pm_define = {
>> +'PM_CAP_ACCESS' : 0x1,
>> +'PM_CAP_CONTEXT' : 0x2,
>> +'PM_CAP_WAKEUP' : 0x4,
>> +
>> +'NODE_UNKNOWN': 0,
>> +'NODE_APU': 1,
>> +'NODE_APU_0' : 2,
>> +'NODE_APU_1' : 3,
>> +'NODE_APU_2' : 4,
>> +'NODE_APU_3' : 5,
>> +'NODE_RPU': 6,
>> +'NODE_RPU_0' : 7,
>> +'NODE_RPU_1' : 8,
>> +'NODE_PLD': 9,
>> +'NODE_FPD': 10,
>> +'NODE_OCM_BANK_0' : 11,
>> +'NODE_OCM_BANK_1' : 12,
>> +'NODE_OCM_BANK_2' : 13,
>> +'NODE_OCM_BANK_3' : 14,
>> +'NODE_TCM_0_A': 15,
>> +'NODE_TCM_0_B': 16,
>> +'NODE_TCM_1_A': 17,
>> +'NODE_TCM_1_B': 18,
>> +'NODE_L2' : 19,
>> +'NODE_GPU_PP_0' : 20,
>> +'NODE_GPU_PP_1' : 21,
>> +'NODE_USB_0' : 22,
>> +'NODE_USB_1' : 23,
>> +'NODE_TTC_0' : 24,
>> +'NODE_TTC_1' : 25,
>> +'NODE_TTC_2' : 26,
>> +'NODE_TTC_3' : 27,
>> +'NODE_SATA' : 28,
>> +'NODE_ETH_0' : 29,
>> +'NODE_ETH_1' : 30,
>> +'NODE_ETH_2' : 31,
>> +'NODE_ETH_3' : 32,
>> +'NODE_UART_0' : 33,
>> +'NODE_UART_1' : 34,
>> +'NODE_SPI_0' : 35,
>> +'NODE_SPI_1' : 36,
>> +'NODE_I2C_0' : 37,
>> +'NODE_I2C_1' : 38,
>> +'NODE_SD_0' : 39,
>> +'NODE_SD_1' : 40,
>> +'NODE_DP' : 41,
>> +'NODE_GDMA' : 42,
>> +'NODE_ADMA' : 43,
>> +'NODE_NAND' : 44,
>> +'NODE_QSPI' : 45,
>> +'NODE_GPIO' : 46,
>> +'NODE_CAN_0' : 47,
>> +'NODE_CAN_1' : 48,
>> +'NODE_EXTERN' : 49,
>> +'NODE_APLL' : 50,
>> +'NODE_VPLL' : 51,
>> +'NODE_DPLL' : 52,
>> +'NODE_RPLL' : 53,
>> +'NODE_IOPLL' : 54,
>> +'NODE_DDR': 55,
>> +'NODE_IPI_APU': 56,
>> +'NODE_IPI_RPU_0' : 57,
>> +'NODE_GPU': 58,
>> +'NODE_PCIE' : 59,
>> +'NODE_PCAP' : 60,
>> +'NODE_RTC': 61,
>> +'NODE_
[U-Boot] [PATCH v3 2/2] arm64: zynqmp: add tool to convert PMU config object .c to binary
The recently-added ZYNQMP_LOAD_PM_CFG_OBJ_FILE option allows SPL to load a
PMUFW configuration object from a binary blob. However the configuration
object is produced by Xilinx proprietary tools as a C source file and no
tool exists to easily convert it to a binary blob in an embedded Linux
build system for U-Boot to use.
Add a simple Python script to do the conversion.
It is definitely not a complete C language parser, but it is enough to
parse the known patterns generated by Xilinx tools, including:
- defines
- literal integers, optionally with a 'U' suffix
- bitwise OR between them
Signed-off-by: Luca Ceresoli
---
arch/arm/mach-zynqmp/pm_cfg_obj_convert.py | 302 +
1 file changed, 302 insertions(+)
create mode 100755 arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
diff --git a/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
new file mode 100755
index ..5aea15860319
--- /dev/null
+++ b/arch/arm/mach-zynqmp/pm_cfg_obj_convert.py
@@ -0,0 +1,302 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Luca Ceresoli
+
+import sys
+import re
+import struct
+import logging
+import argparse
+
+parser = argparse.ArgumentParser(
+description='Convert a PMU configuration object from C source to a binary
blob.',
+allow_abbrev=False)
+parser.add_argument('-D', '--debug', action="store_true")
+parser.add_argument(
+"in_file", metavar='INPUT_FILE',
+help='PMU configuration object (C source as produced by Xilinx XSDK)')
+parser.add_argument(
+"out_file", metavar='OUTPUT_FILE',
+help='PMU configuration object binary blob')
+args = parser.parse_args()
+
+logging.basicConfig(format='%(levelname)s:%(message)s',
+level=(logging.DEBUG if args.debug else logging.WARNING))
+
+pm_define = {
+'PM_CAP_ACCESS' : 0x1,
+'PM_CAP_CONTEXT' : 0x2,
+'PM_CAP_WAKEUP' : 0x4,
+
+'NODE_UNKNOWN': 0,
+'NODE_APU': 1,
+'NODE_APU_0' : 2,
+'NODE_APU_1' : 3,
+'NODE_APU_2' : 4,
+'NODE_APU_3' : 5,
+'NODE_RPU': 6,
+'NODE_RPU_0' : 7,
+'NODE_RPU_1' : 8,
+'NODE_PLD': 9,
+'NODE_FPD': 10,
+'NODE_OCM_BANK_0' : 11,
+'NODE_OCM_BANK_1' : 12,
+'NODE_OCM_BANK_2' : 13,
+'NODE_OCM_BANK_3' : 14,
+'NODE_TCM_0_A': 15,
+'NODE_TCM_0_B': 16,
+'NODE_TCM_1_A': 17,
+'NODE_TCM_1_B': 18,
+'NODE_L2' : 19,
+'NODE_GPU_PP_0' : 20,
+'NODE_GPU_PP_1' : 21,
+'NODE_USB_0' : 22,
+'NODE_USB_1' : 23,
+'NODE_TTC_0' : 24,
+'NODE_TTC_1' : 25,
+'NODE_TTC_2' : 26,
+'NODE_TTC_3' : 27,
+'NODE_SATA' : 28,
+'NODE_ETH_0' : 29,
+'NODE_ETH_1' : 30,
+'NODE_ETH_2' : 31,
+'NODE_ETH_3' : 32,
+'NODE_UART_0' : 33,
+'NODE_UART_1' : 34,
+'NODE_SPI_0' : 35,
+'NODE_SPI_1' : 36,
+'NODE_I2C_0' : 37,
+'NODE_I2C_1' : 38,
+'NODE_SD_0' : 39,
+'NODE_SD_1' : 40,
+'NODE_DP' : 41,
+'NODE_GDMA' : 42,
+'NODE_ADMA' : 43,
+'NODE_NAND' : 44,
+'NODE_QSPI' : 45,
+'NODE_GPIO' : 46,
+'NODE_CAN_0' : 47,
+'NODE_CAN_1' : 48,
+'NODE_EXTERN' : 49,
+'NODE_APLL' : 50,
+'NODE_VPLL' : 51,
+'NODE_DPLL' : 52,
+'NODE_RPLL' : 53,
+'NODE_IOPLL' : 54,
+'NODE_DDR': 55,
+'NODE_IPI_APU': 56,
+'NODE_IPI_RPU_0' : 57,
+'NODE_GPU': 58,
+'NODE_PCIE' : 59,
+'NODE_PCAP' : 60,
+'NODE_RTC': 61,
+'NODE_LPD': 62,
+'NODE_VCU': 63,
+'NODE_IPI_RPU_1' : 64,
+'NODE_IPI_PL_0' : 65,
+'NODE_IPI_PL_1' : 66,
+'NODE_IPI_PL_2' : 67,
+'NODE_IPI_PL_3' : 68,
+'NODE_PL' : 69,
+'NODE_ID_MA' : 70,
+
+'XILPM_RESET_PCIE_CFG' : 1000,
+'XILPM_RESET_PCIE_BRIDGE' : 1001,
+'XILPM_RESET_PCIE_CTRL': 1002,
+'XILPM_RESET_DP' : 1003,
+'XILPM_RESET_SWDT_CRF' : 1004,
+'XILPM_RESET_AFI_FM5' : 1005,
+'XILPM_RESET_AFI_FM4' : 1006,
+'XILPM_RESET_AFI_FM3' : 1007,
+'XILPM_RESET_AFI_FM2' : 1008,
+'XILPM_RESET_AFI_FM1' : 1009,
+'XILPM_RESET_AFI_FM0' : 1010,
+'XILPM_RESET_GDMA' : 1011,
+'XILPM_RESET_GPU_PP1' : 1012,
+'XILPM_RESET_GPU_PP0' : 1013,
+'XILPM_RESET_GPU' : 1014,
+'XILPM_RESET_GT' : 1015,
+'XILPM_RESET_SATA' : 1016,
+'XILPM_RESET_ACPU3_PWRON' : 1017,
+'XILPM_RESET_ACPU2_PWRON' : 1018,
+'XILPM_RESET_ACPU1_PWRON' : 1019,
+'XILPM_RESET_ACPU0_PWRON' : 1020,
+'XILPM_RESET_APU_L2' :
[U-Boot] [PATCH v3 1/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Optionally allow U-Boot to load at the PMU firmware configuration object into the Power Management Unit (PMU) on Xilinx ZynqMP. The configuration object is required by the PMU FW to enable most SoC peripherals. So far the only way to boot using U-Boot SPL was to hard-code the configuration object in the PMU firmware. Allow a different boot process, where the PMU FW is equal for any ZynqMP chip and its configuration is passed at runtime by U-Boot SPL. All the code for Inter-processor communication with the PMU is isolated in a new file (pmu_ipc.c). The code is inspired by the same feature as implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted Firmware: * https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295 * https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357 SPL logs on the console before loading the configuration object: U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21) Loading PMUFW cfg obj (2008 bytes) EL Level: EL3 ... Signed-off-by: Luca Ceresoli --- Changes RFC v2 -> v3: - don't compile pm_cfg_obj.c from source, load it from a binary file (suggested by Michal) - move IPC code to arch/arm/mach-zynqmp/ and sys_proto.h (Michal) Changes RFC v1 -> RFC v2: - Load the cfg_obj in SPL, not U-Boot proper: this required a complete reimplementation since we cannot rely on ATF now - Update and refine the Kconfig option help --- arch/arm/mach-zynqmp/Kconfig | 17 +++ arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 4 + arch/arm/mach-zynqmp/pmu_ipc.c| 112 ++ board/xilinx/zynqmp/Makefile | 12 ++ board/xilinx/zynqmp/pm_cfg_obj.S | 17 +++ board/xilinx/zynqmp/zynqmp.c | 8 ++ 7 files changed, 174 insertions(+) create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig index 9bb5a5c20201..b88d1d313839 100644 --- a/arch/arm/mach-zynqmp/Kconfig +++ b/arch/arm/mach-zynqmp/Kconfig @@ -65,6 +65,23 @@ config PMUFW_INIT_FILE Include external PMUFW (Platform Management Unit FirmWare) to a Xilinx bootable image (boot.bin). +config ZYNQMP_LOAD_PM_CFG_OBJ_FILE + string "PMU firmware configuration object to load at runtime" + help + + Path to a binary PMU firmware configuration object to be linked + into U-Boot SPL and loaded at runtime into the PMU firmware. + + The ZynqMP Power Management Unit (PMU) needs a configuration + object for most SoC peripherals to work. To have it loaded by + U-Boot SPL set here the file name (absolute path or relative to + board/xilinx/zynqmp/) of your configuration, which must be a + binary blob. It will be linked in the SPL binary and loaded into + the PMU firmware by U-Boot SPL during board initialization. + + Leave this option empty if your PMU firmware has a hard-coded + configuration object or you are loading it by any other means. + config ZYNQMP_USB bool "Configure ZynqMP USB" diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile index 8a3b0747244a..d391b7c1d54e 100644 --- a/arch/arm/mach-zynqmp/Makefile +++ b/arch/arm/mach-zynqmp/Makefile @@ -8,3 +8,7 @@ obj-y += cpu.o obj-$(CONFIG_MP) += mp.o obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED) += psu_spl_init.o + +ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"") +obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o +endif diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h b/arch/arm/mach-zynqmp/include/mach/sys_proto.h index 385c8825f2f6..e2b9a79ed539 100644 --- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h +++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h @@ -72,4 +72,8 @@ int chip_id(unsigned char id); void tcm_init(u8 mode); #endif +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ) +void zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size); +#endif + #endif /* _ASM_ARCH_SYS_PROTO_H */ diff --git a/arch/arm/mach-zynqmp/pmu_ipc.c b/arch/arm/mach-zynqmp/pmu_ipc.c new file mode 100644 index ..5feb8568f8de --- /dev/null +++ b/arch/arm/mach-zynqmp/pmu_ipc.c @@ -0,0 +1,112 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Inter-Processor Communication with the Platform Management Unit (PMU) + * firmware. + * + * (C) Copyright 2019 Luca Ceresoli + * Luca Ceresoli + */ + +#include +#include +#include + +/* IPI bitmasks, register base and register offsets */ +#define IPI_BIT_MASK_APU 0x1 +#define IPI_BIT_MASK_PMU0 0x1 +#define IPI_REG_BASE_APU 0xFF3000
[U-Boot] [PATCH v3 0/2] arm64: zynqmp: pass a PMUFW config object
Hi, This patchset aims at solving a long-standing issue in the ZynqMP users community: the management of the PMU firmware configuration object when U-Boot SPL is used. History and status == First non-RFC version. The code is now clean and I consider it OK for mainline inclusion. Since RFC v2 the cfg obj is now passed as a binary blob. The code to compile it in the C form has been removed and replaced by a Python tool to convert C to bin. The loading has been fixed and cleaned up according to comments. TODO: move the PMU IPC code to a mailbox uclass driver. Description === The Platform Management Unit (PMU) needs a configuration object (cfg obj) to know how to operate the SoC. When using the "Xilinx workflow", the Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot proper. This is just not implemented in the U-Boot code. The best workaround for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj built-in and self-load it. This approach has some drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuation. It also makes it impossible to change the configuration after boot. The first patch fills the gap by allowing U-Boot SPL to load the cfg obj firmware at runtime. It adds a Kconfig string option to point to the cfg obj in the form of a binary blob. If the option is non-empty, code is enabled to link that file in U-Boot SPL and send the configuration to PMUFW. Patch 2 adds a tool to convert the cfg obj C file (as produced by the Xilinx XSDK proprietary tool) in a binary blob suitable for loading. As suggested by Mike Looijmans it has been implemented as a Python script to make it easily usable. These patches are tested on the UltraZed EV board. Many thanks to Michal Simek for his many suggestions on how to improve this work. [0] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch RFCv1: https://lists.denx.de/pipermail/u-boot/2019-February/360450.html RFCv2: https://lists.denx.de/pipermail/u-boot/2019-March/362464.html Luca Luca Ceresoli (2): arm64: zynqmp: spl: install a PMU firmware config object at runtime arm64: zynqmp: add tool to convert PMU config object .c to binary arch/arm/mach-zynqmp/Kconfig | 17 + arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/include/mach/sys_proto.h | 4 + arch/arm/mach-zynqmp/pm_cfg_obj_convert.py| 302 ++ arch/arm/mach-zynqmp/pmu_ipc.c| 112 +++ board/xilinx/zynqmp/Makefile | 12 + board/xilinx/zynqmp/pm_cfg_obj.S | 17 + board/xilinx/zynqmp/zynqmp.c | 8 + 8 files changed, 476 insertions(+) create mode 100755 arch/arm/mach-zynqmp/pm_cfg_obj_convert.py create mode 100644 arch/arm/mach-zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pm_cfg_obj.S -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: fix preprocessor check for SPL_ZYNQMP_TWO_SDHCI
A missing CONFIG_ prefix while checking for this Kconfig variable makes the
check always fail. Fix it. While there also switch from the '#if defined'
form to the '#ifdef' form as the other checks in this function.
Fixes: 35e2b92344b1 ("arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI")
Signed-off-by: Luca Ceresoli
---
arch/arm/mach-zynqmp/spl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index f6f5414201b5..b7d2ecdf7257 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -85,7 +85,7 @@ u32 spl_boot_device(void)
case SD_MODE1:
case SD1_LSHFT_MODE: /* not working on silicon v1 */
/* if both controllers enabled, then these two are the second controller */
-#if defined(SPL_ZYNQMP_TWO_SDHCI)
+#ifdef CONFIG_SPL_ZYNQMP_TWO_SDHCI
return BOOT_DEVICE_MMC2;
/* else, fall through, the one SDHCI controller that is enabled is number 1 */
#endif
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] i2c: muxes: pca954x: support PCA9543 I2C switch
The PCA9543 is a 2-channel I2C switch.
Signed-off-by: Luca Ceresoli
Reviewed-by: Heiko Schocher
---
Changes v1 -> v2:
- rebase on current tree
---
drivers/i2c/muxes/Kconfig | 3 ++-
drivers/i2c/muxes/pca954x.c | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 4a601c88b78f..68f15261be77 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -33,7 +33,8 @@ config I2C_MUX_PCA954x
devices. It is x width I2C multiplexer which enables to partitioning
I2C bus and connect multiple devices with the same address to the same
I2C controller where driver handles proper routing to target i2c
- device. Supported chips are PCA9544, PCA9547, PCA9548 and PCA9646.
+ device. Supported chips are PCA9543, PCA9544, PCA9547, PCA9548 and
+ PCA9646.
config I2C_MUX_GPIO
tristate "GPIO-based I2C multiplexer"
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index 5669753ce14d..a630ce991d04 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -15,6 +15,7 @@
DECLARE_GLOBAL_DATA_PTR;
enum pca_type {
+ PCA9543,
PCA9544,
PCA9547,
PCA9548,
@@ -37,6 +38,10 @@ struct pca954x_priv {
};
static const struct chip_desc chips[] = {
+ [PCA9543] = {
+ .muxtype = pca954x_isswi,
+ .width = 2,
+ },
[PCA9544] = {
.enable = 0x4,
.muxtype = pca954x_ismux,
@@ -87,6 +92,7 @@ static const struct i2c_mux_ops pca954x_ops = {
};
static const struct udevice_id pca954x_ids[] = {
+ { .compatible = "nxp,pca9543", .data = PCA9543 },
{ .compatible = "nxp,pca9544", .data = PCA9544 },
{ .compatible = "nxp,pca9547", .data = PCA9547 },
{ .compatible = "nxp,pca9548", .data = PCA9548 },
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] i2c: muxes: pca954x: clarify enable field
The chip_desc.enable field is used only for muxes, not for switches.
Document it and remove the unused values.
Signed-off-by: Luca Ceresoli
Reviewed-by: Heiko Schocher
---
Changes v1 -> v2:
- fix typo in commit message (Michal)
---
drivers/i2c/muxes/pca954x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index bd4e9abe5f3c..5669753ce14d 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -22,7 +22,7 @@ enum pca_type {
};
struct chip_desc {
- u8 enable;
+ u8 enable; /* Enable mask in ctl register (used for muxes only) */
enum muxtype {
pca954x_ismux = 0,
pca954x_isswi,
@@ -48,12 +48,10 @@ static const struct chip_desc chips[] = {
.width = 8,
},
[PCA9548] = {
- .enable = 0x8,
.muxtype = pca954x_isswi,
.width = 8,
},
[PCA9646] = {
- .enable = 0x0,
.muxtype = pca954x_isswi,
.width = 4,
},
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] i2c: muxes: pca954x: update list of supported devices
The Kconfig help has not been updated while adding PCA9547 and PCA9646. Signed-off-by: Luca Ceresoli --- Changes v1 -> v2: - add missing comma (Michal) - reword and rewrap the sentence --- drivers/i2c/muxes/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig index b0da67ce2c6b..4a601c88b78f 100644 --- a/drivers/i2c/muxes/Kconfig +++ b/drivers/i2c/muxes/Kconfig @@ -29,11 +29,11 @@ config I2C_MUX_PCA954x tristate "TI PCA954x I2C Mux/switches" depends on I2C_MUX help - If you say yes here you get support for the TI PCA954x - I2C mux/switch devices. It is x width I2C multiplexer which enables to - partitioning I2C bus and connect multiple devices with the same address - to the same I2C controller where driver handles proper routing to - target i2c device. PCA9544 and PCA9548 are supported. + If you say yes here you get support for the TI PCA954x I2C mux/switch + devices. It is x width I2C multiplexer which enables to partitioning + I2C bus and connect multiple devices with the same address to the same + I2C controller where driver handles proper routing to target i2c + device. Supported chips are PCA9544, PCA9547, PCA9548 and PCA9646. config I2C_MUX_GPIO tristate "GPIO-based I2C multiplexer" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] i2c: muxes: pca954x: update list of supported devices
Hi Michal, On 05/04/19 12:58, Michal Simek wrote: > On 05. 04. 19 12:32, Luca Ceresoli wrote: >> The Kconfig help has not been updated while adding PCA9547 and PCA9646. >> >> Signed-off-by: Luca Ceresoli >> --- >> drivers/i2c/muxes/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig >> index b0da67ce2c6b..26be78f685de 100644 >> --- a/drivers/i2c/muxes/Kconfig >> +++ b/drivers/i2c/muxes/Kconfig >> @@ -33,7 +33,7 @@ config I2C_MUX_PCA954x >>I2C mux/switch devices. It is x width I2C multiplexer which enables to >>partitioning I2C bus and connect multiple devices with the same >> address >>to the same I2C controller where driver handles proper routing to >> - target i2c device. PCA9544 and PCA9548 are supported. >> + target i2c device. PCA9544, PCA9547 PCA9548 and PCA9646 are supported. > > missing comma there. Thank you for your very prompt reviews. I'll wait a few more days in case of more comments and then resend with the fixes you suggested. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] i2c: muxes: pca954x: support PCA9543 I2C switch
The PCA9543 is a 2-channel I2C switch.
Signed-off-by: Luca Ceresoli
---
drivers/i2c/muxes/Kconfig | 10 +-
drivers/i2c/muxes/pca954x.c | 6 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 26be78f685de..7de4977c9c4a 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -29,11 +29,11 @@ config I2C_MUX_PCA954x
tristate "TI PCA954x I2C Mux/switches"
depends on I2C_MUX
help
- If you say yes here you get support for the TI PCA954x
- I2C mux/switch devices. It is x width I2C multiplexer which enables to
- partitioning I2C bus and connect multiple devices with the same
address
- to the same I2C controller where driver handles proper routing to
- target i2c device. PCA9544, PCA9547 PCA9548 and PCA9646 are supported.
+ If you say yes here you get support for the TI PCA954x I2C mux/switch
+ devices. It is x width I2C multiplexer which enables to partitioning
+ I2C bus and connect multiple devices with the same address to the same
+ I2C controller where driver handles proper routing to target i2c
+ device. PCA9543, PCA9544, PCA9547 PCA9548 and PCA9646 are supported.
config I2C_MUX_GPIO
tristate "GPIO-based I2C multiplexer"
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index 5669753ce14d..a630ce991d04 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -15,6 +15,7 @@
DECLARE_GLOBAL_DATA_PTR;
enum pca_type {
+ PCA9543,
PCA9544,
PCA9547,
PCA9548,
@@ -37,6 +38,10 @@ struct pca954x_priv {
};
static const struct chip_desc chips[] = {
+ [PCA9543] = {
+ .muxtype = pca954x_isswi,
+ .width = 2,
+ },
[PCA9544] = {
.enable = 0x4,
.muxtype = pca954x_ismux,
@@ -87,6 +92,7 @@ static const struct i2c_mux_ops pca954x_ops = {
};
static const struct udevice_id pca954x_ids[] = {
+ { .compatible = "nxp,pca9543", .data = PCA9543 },
{ .compatible = "nxp,pca9544", .data = PCA9544 },
{ .compatible = "nxp,pca9547", .data = PCA9547 },
{ .compatible = "nxp,pca9548", .data = PCA9548 },
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] i2c: muxes: pca954x: update list of supported devices
The Kconfig help has not been updated while adding PCA9547 and PCA9646. Signed-off-by: Luca Ceresoli --- drivers/i2c/muxes/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig index b0da67ce2c6b..26be78f685de 100644 --- a/drivers/i2c/muxes/Kconfig +++ b/drivers/i2c/muxes/Kconfig @@ -33,7 +33,7 @@ config I2C_MUX_PCA954x I2C mux/switch devices. It is x width I2C multiplexer which enables to partitioning I2C bus and connect multiple devices with the same address to the same I2C controller where driver handles proper routing to - target i2c device. PCA9544 and PCA9548 are supported. + target i2c device. PCA9544, PCA9547 PCA9548 and PCA9646 are supported. config I2C_MUX_GPIO tristate "GPIO-based I2C multiplexer" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] i2c: muxes: pca954x: clarify enable field
The chip_desc.enable field is used only for muxes, not tor switches.
Document it and remove the unused values.
Signed-off-by: Luca Ceresoli
---
drivers/i2c/muxes/pca954x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index bd4e9abe5f3c..5669753ce14d 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -22,7 +22,7 @@ enum pca_type {
};
struct chip_desc {
- u8 enable;
+ u8 enable; /* Enable mask in ctl register (used for muxes only) */
enum muxtype {
pca954x_ismux = 0,
pca954x_isswi,
@@ -48,12 +48,10 @@ static const struct chip_desc chips[] = {
.width = 8,
},
[PCA9548] = {
- .enable = 0x8,
.muxtype = pca954x_isswi,
.width = 8,
},
[PCA9646] = {
- .enable = 0x0,
.muxtype = pca954x_isswi,
.width = 4,
},
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi Mike, Michal,
On 04/04/19 08:49, Michal Simek wrote:
[...]
>>> +#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
>>> +#include CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE
>>> +#endif
>>> +
>>>int board_early_init_f(void)
>>>{
>>> int ret = 0;
>>> @@ -332,6 +338,11 @@ int board_early_init_f(void)
>>>
>>>int board_init(void)
>>>{
>>> +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ)
>>> + zynqmp_pmufw_load_config_object(XPm_ConfigObject,
>>> + sizeof(XPm_ConfigObject));
>>> +#endif
>>
>> As we discussed over IRC. I think that this should be simply bin
>> firmware file compare to C built by u-boot.
>
> Sure. I have a working prototype that uses a binary blob. It still needs
> a decent way to produce a blob and to be updated according to your review.
It should be doable to write a Python script to parse the C file and
create an
equivalent binary (using "struct" module) which is just an array of
integers
in the end. That avoids the need for a microblaze C compiler...
>>>
>>> There's no need for a microblaze compiler. pm_cfg_obj.c is simply
>>> declaring a u32 array and some #defines, any C compiler is enough.
>>>
>>> That said, my current solution (a trivial main.c that compiles the u32
>>> array and outputs it to a binary file) is not nice at all, and it
>>> requires a pm_defs.h file.
>>>
>>> The python script you mention looks way better from a user perspective,
>>> although the parsing might be a bit fragile. I'll consider it, thanks
>>> for the suggestion.
>>>
>>> In the past I even prototyped a python script that parses the Vivado
>>> .xpr project file and produces a pm_cfg_obj.c. It avoided the need to
>>> run the Xilinx XSDK just to generate pm_cfg_obj.c. It might also be
>>> extended to produce a .bin directly, or a self-standing .c file that
>>> doesn't need pm_defs.h, thus removing any licensing issue. But it never
>>> grew complete to handle all cases. Obvious, since *I* don't even know
>>> all of the cases. :)
>>
>>
>> Another approach would be to simply create and include a "god mode" config
>> object that just allows access to all periferals. As far as I can see, such
>> a
>> config object would just work on all boards. There's nothing really board
>> specific in the config object, and it's rather lame anyway to have to go and
>> compile a new bootloader just because you want to use a SPI controller...
>>
>> The config object I compile into the pmu firmware is of that type anyway.
Oh, that's interesting, but read below.
> Most of that stuff should be the same for all boards. But there are some
> stuff which can be just board specific.
Mike, I think Michal refers to boards like Ultra96 which need special
GPIO handling for their boot sequence, whose pm_cfg_obj.c have a final
section similar to this:
/* GPO SECTION */
PM_CONFIG_GPO_SECTION_ID, /* GPO Section ID */
PM_CONFIG_GPO1_BIT_2_MASK |
PM_CONFIG_GPO1_MIO_PIN_34_MAP |
0, /* State of GPO pins */
I suspect a "god mode" config cannot handle such cases.
--
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi Mike,
On 03/04/19 13:24, Mike Looijmans wrote:
> On 29-03-19 13:22, Luca Ceresoli wrote:
>> Hi Michal,
>>
>> thanks for the feedback.
>>
>> On 27/03/19 16:03, Michal Simek wrote:
>>> On 21. 03. 19 16:48, Luca Ceresoli wrote:
>>>> Optionally allow U-Boot to load at the PMU firmware configuration object
>>>> into the Power Management Unit (PMU) on Xilinx ZynqMP.
>>>>
>>>> The configuration object is required by the PMU FW to enable most SoC
>>>> peripherals. So far the only way to boot using U-Boot SPL was to hard-code
>>>> the configuration object in the PMU firmware. Allow a different boot
>>>> process, where the PMU FW is equal for any ZynqMP chip and its
>>>> configuration is passed at runtime by U-Boot SPL.
>>>>
>>>> All the code for Inter-processor communication with the PMU is isolated in
>>>> a new file (pmu_ipc.c). The code is inspired by the same feature as
>>>> implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
>>>> Firmware:
>>>>
>>>> *
>>>> https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
>>>> *
>>>> https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357
>>>>
>>>> The load is logged on the console during boot:
>>>>
>>>>U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
>>>>Loading PMUFW cfg obj (2008 bytes)
>>>>EL Level: EL3
>>>>...
>>>>
>>>> Signed-off-by: Luca Ceresoli
>> [...]
>>>> diff --git a/board/xilinx/zynqmp/pmu_ipc.c b/board/xilinx/zynqmp/pmu_ipc.c
>>>> new file mode 100644
>>>> index ..6306d33d6f17
>>>> --- /dev/null
>>>> +++ b/board/xilinx/zynqmp/pmu_ipc.c
>>>> @@ -0,0 +1,116 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Inter-Processor Communication with the Platform Management Unit (PMU)
>>>> + * firmware.
>> [...]
>>>> +static int pmu_ipc_request(const u32 *req, size_t req_len,
>>>> + u32 *res, size_t res_maxlen)
>>>> +{
>>>> + u32 status;
>>>> +
>>>> + if (req_len > PMUFW_PAYLOAD_ARG_CNT ||
>>>> + res_maxlen > PMUFW_PAYLOAD_ARG_CNT)
>>>> + return -EINVAL;
>>>> +
>>>> + pmu_ipc_send_request(req, req_len);
>>>> +
>>>> + /* Raise Inter-Processor Interrupt to PMU and wait for response */
>>>> + writel(IPI_BIT_MASK_PMU0, IPI_REG_BASE_APU + IPI_REG_OFFSET_TRIG);
>>>> + do {
>>>> + status = readl(IPI_REG_BASE_APU + IPI_REG_OFFSET_OBR);
>>>> + } while (status & IPI_BIT_MASK_PMU0);
>>>> +
>>>> + pmu_ipc_read_response(res, res_maxlen);
>>>> +
>>>> + return 0;
>>>> +}
>>>
>>> All above should be mailbox driver. It means this should go to
>>> drivers/mailbox and be split to mbox send/recv functions.
>>
>> Oh, wow, there's a mailbox uclass! I'll have a look into it.
>>
>>> But I have no problem to use this configuration in the first patch and
>>> move to mbox driver in separate patch.
>>
>> Good to know, I'll use this option in case it takes too long to make it
>> a proper mailbox driver.
>>
>>>> +/**
>>>> + * Send a configuration object to the PMU firmware.
>>>> + *
>>>> + * @cfg_obj Pointer to the configuration object
>>>> + * @sizeSize of @cfg_obj in bytes
>>>> + */
>>>> +void zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size)
>>>> +{
>>>> + const u32 *ocm = (u32 *)CONFIG_SPL_TEXT_BASE;
>>>> + const u32 request[] = {
>>>> + PMUFW_CMD_SET_CONFIGURATION,
>>>> + CONFIG_SPL_TEXT_BASE
>>>> + };
>>>> + u32 response;
>>>> + int err;
>>>> +
>>>> + printf("Loading PMUFW cfg obj (%ld bytes)\n", size);
>>>> +
>>>> + memcpy(ocm, cfg_obj, size);
>>>> +
>>>> + err = pmu_ipc_request(request, ARRAY_SIZE(request), , 1);
>>>> + if (err)
>>>> + panic("Cannot load PMUFW configuration object (%d)\n", err);
>>>> + if (
Re: [U-Boot] [RFC v2 1/2] zynqmp: add minimal include files to build a pm_cfg_obj.c
Hi Michal, On 27/03/19 16:10, Michal Simek wrote: > On 21. 03. 19 16:48, Luca Ceresoli wrote: >> A following commit will allow U-Boot to pass a configuration object to >> the ZynqMP PMU firmware. This configuration object is generated by >> Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a >> few headers with constants definitions. >> >> In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal >> version of those headers files: >> >> - pm_defs: a copy of [0], reduced to remove unneeded values >> - pmu_global.h: empty file, it is included but not really needed >> - xil_types.h: just includes common.h which has all the needed types >> >> [0] >> https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h >> >> Signed-off-by: Luca Ceresoli >> --- >> board/xilinx/zynqmp/pm_defs.h| 254 +++ >> board/xilinx/zynqmp/pmu_global.h | 0 >> board/xilinx/zynqmp/xil_types.h | 1 + >> 3 files changed, 255 insertions(+) >> create mode 100644 board/xilinx/zynqmp/pm_defs.h >> create mode 100644 board/xilinx/zynqmp/pmu_global.h >> create mode 100644 board/xilinx/zynqmp/xil_types.h [...] > > I found one version of this file with GPL license. Of pm_defs.h? Interesting, where can I find it? > But even that > I think this should be taken as blob and compiled/generated out of > u-boot source code. Still pm_cfg_obj.c has no GPL license in it. Yes, sure. But still we need a pm_defs.h if we want to obtain a blob out of a Xilinx-generated pm_cfg_obj.c, so the GPL'ed file you mentioned would be useful. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Hi Michal,
thanks for the feedback.
On 27/03/19 16:03, Michal Simek wrote:
> On 21. 03. 19 16:48, Luca Ceresoli wrote:
>> Optionally allow U-Boot to load at the PMU firmware configuration object
>> into the Power Management Unit (PMU) on Xilinx ZynqMP.
>>
>> The configuration object is required by the PMU FW to enable most SoC
>> peripherals. So far the only way to boot using U-Boot SPL was to hard-code
>> the configuration object in the PMU firmware. Allow a different boot
>> process, where the PMU FW is equal for any ZynqMP chip and its
>> configuration is passed at runtime by U-Boot SPL.
>>
>> All the code for Inter-processor communication with the PMU is isolated in
>> a new file (pmu_ipc.c). The code is inspired by the same feature as
>> implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
>> Firmware:
>>
>> *
>> https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
>> *
>> https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357
>>
>> The load is logged on the console during boot:
>>
>> U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
>> Loading PMUFW cfg obj (2008 bytes)
>> EL Level: EL3
>> ...
>>
>> Signed-off-by: Luca Ceresoli
[...]
>> diff --git a/board/xilinx/zynqmp/pmu_ipc.c b/board/xilinx/zynqmp/pmu_ipc.c
>> new file mode 100644
>> index ..6306d33d6f17
>> --- /dev/null
>> +++ b/board/xilinx/zynqmp/pmu_ipc.c
>> @@ -0,0 +1,116 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Inter-Processor Communication with the Platform Management Unit (PMU)
>> + * firmware.
[...]
>> +static int pmu_ipc_request(const u32 *req, size_t req_len,
>> + u32 *res, size_t res_maxlen)
>> +{
>> +u32 status;
>> +
>> +if (req_len > PMUFW_PAYLOAD_ARG_CNT ||
>> +res_maxlen > PMUFW_PAYLOAD_ARG_CNT)
>> +return -EINVAL;
>> +
>> +pmu_ipc_send_request(req, req_len);
>> +
>> +/* Raise Inter-Processor Interrupt to PMU and wait for response */
>> +writel(IPI_BIT_MASK_PMU0, IPI_REG_BASE_APU + IPI_REG_OFFSET_TRIG);
>> +do {
>> +status = readl(IPI_REG_BASE_APU + IPI_REG_OFFSET_OBR);
>> +} while (status & IPI_BIT_MASK_PMU0);
>> +
>> +pmu_ipc_read_response(res, res_maxlen);
>> +
>> +return 0;
>> +}
>
> All above should be mailbox driver. It means this should go to
> drivers/mailbox and be split to mbox send/recv functions.
Oh, wow, there's a mailbox uclass! I'll have a look into it.
> But I have no problem to use this configuration in the first patch and
> move to mbox driver in separate patch.
Good to know, I'll use this option in case it takes too long to make it
a proper mailbox driver.
>> +/**
>> + * Send a configuration object to the PMU firmware.
>> + *
>> + * @cfg_obj Pointer to the configuration object
>> + * @sizeSize of @cfg_obj in bytes
>> + */
>> +void zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size)
>> +{
>> +const u32 *ocm = (u32 *)CONFIG_SPL_TEXT_BASE;
>> +const u32 request[] = {
>> +PMUFW_CMD_SET_CONFIGURATION,
>> +CONFIG_SPL_TEXT_BASE
>> +};
>> +u32 response;
>> +int err;
>> +
>> +printf("Loading PMUFW cfg obj (%ld bytes)\n", size);
>> +
>> +memcpy(ocm, cfg_obj, size);
>> +
>> +err = pmu_ipc_request(request, ARRAY_SIZE(request), , 1);
>> +if (err)
>> +panic("Cannot load PMUFW configuration object (%d)\n", err);
>> +if (response != 0)
>> +panic("PMUFW returned 0x%08x status!\n", response);
>> +}
>
> And this can stay here or go to arch/arm/mach-zynq/
Ok, I'll move it to arch/arm/mach-zynq/pmu.c or so.
I assume "zynq" here means the whole zynq family, including zynqmp.
>> diff --git a/board/xilinx/zynqmp/pmu_ipc.h b/board/xilinx/zynqmp/pmu_ipc.h
>> new file mode 100644
>> index ..37bb72c1b20a
>> --- /dev/null
>> +++ b/board/xilinx/zynqmp/pmu_ipc.h
>> @@ -0,0 +1,14 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * (C) Copyright 2019 Luca Ceresoli
>> + * Luca Ceresoli
>> + */
>> +
>> +#ifndef __ZYNQMP_PMU_IPC_H__
>> +#define __ZYNQMP_PMU_IPC_H__
>> +
>> +#include
>> +
>> +void zynqmp_pm
[U-Boot] [RFC v2 0/2] arm64: zynqmp: pass a PMUFW config object
Hi, a long-standing issue in the ZynqMP users community is the management on the PMU firmware configuration object when U-Boot SPL is used. The Platform Management Unit (PMU) needs a configuration object (cfg obj) to know how to operate the SoC. When using the "Xilinx workflow", the Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot proper. This is just not implemented in the U-Boot code. The best workaround for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj built-in and self-load it. This approach has some drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuation. It also makes it impossible to change the configuration after boot. This patchset is a first attempt at filling the gap by allowing U-Boot SPL to load the cfg obj firmware at runtime. It adds a Kconfig string option to point to the cfg obj in the form of a C file as produced by Xilinx tools (usually called pm_cfg_obj.c). If the option is non-empty, code is enabled to compile that file in U-Boot SPL and send the configuration to PMUFW. The next development target will be to load the cfg obj from a binary blob instead of compiling it from a .c file. With that in place, patch 1 will be removed and patch 2 cleaned up. These patches are tested on the UltraZed EV board. Since RFC v1 [1] the loading has been reimplemented in SPL (it was in U-Boot proper). Now it does not rely on ARM Trusted Firmware but instead talks directly with the PMU via IPI mailboxes. [0] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch [1] https://lists.denx.de/pipermail/u-boot/2019-February/360450.html Luca Luca Ceresoli (2): zynqmp: add minimal include files to build a pm_cfg_obj.c arm64: zynqmp: spl: install a PMU firmware config object at runtime board/xilinx/zynqmp/Kconfig | 26 board/xilinx/zynqmp/Makefile | 5 + board/xilinx/zynqmp/pm_defs.h| 254 +++ board/xilinx/zynqmp/pmu_global.h | 0 board/xilinx/zynqmp/pmu_ipc.c| 116 ++ board/xilinx/zynqmp/pmu_ipc.h| 14 ++ board/xilinx/zynqmp/xil_types.h | 1 + board/xilinx/zynqmp/zynqmp.c | 11 ++ 8 files changed, 427 insertions(+) create mode 100644 board/xilinx/zynqmp/pm_defs.h create mode 100644 board/xilinx/zynqmp/pmu_global.h create mode 100644 board/xilinx/zynqmp/pmu_ipc.c create mode 100644 board/xilinx/zynqmp/pmu_ipc.h create mode 100644 board/xilinx/zynqmp/xil_types.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC v2 1/2] zynqmp: add minimal include files to build a pm_cfg_obj.c
A following commit will allow U-Boot to pass a configuration object to
the ZynqMP PMU firmware. This configuration object is generated by
Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a
few headers with constants definitions.
In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal
version of those headers files:
- pm_defs: a copy of [0], reduced to remove unneeded values
- pmu_global.h: empty file, it is included but not really needed
- xil_types.h: just includes common.h which has all the needed types
[0]
https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h
Signed-off-by: Luca Ceresoli
---
board/xilinx/zynqmp/pm_defs.h| 254 +++
board/xilinx/zynqmp/pmu_global.h | 0
board/xilinx/zynqmp/xil_types.h | 1 +
3 files changed, 255 insertions(+)
create mode 100644 board/xilinx/zynqmp/pm_defs.h
create mode 100644 board/xilinx/zynqmp/pmu_global.h
create mode 100644 board/xilinx/zynqmp/xil_types.h
diff --git a/board/xilinx/zynqmp/pm_defs.h b/board/xilinx/zynqmp/pm_defs.h
new file mode 100644
index ..a339d5ef4fd1
--- /dev/null
+++ b/board/xilinx/zynqmp/pm_defs.h
@@ -0,0 +1,254 @@
+/**
+*
+* Copyright (C) 2015-2018 Xilinx, Inc. All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a copy
+* of this software and associated documentation files (the "Software"), to deal
+* in the Software without restriction, including without limitation the rights
+* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+* copies of the Software, and to permit persons to whom the Software is
+* furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+* XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+* SOFTWARE.
+*
+* Except as contained in this notice, the name of the Xilinx shall not be used
+* in advertising or otherwise to promote the sale, use or other dealings in
+* this Software without prior written authorization from Xilinx.
+*
+**/
+
+/*/
+/**
+ * @file pm_defs.h
+ *
+ * PM Definitions implementation
+ * @addtogroup xpm_apis XilPM APIs
+ * @{
+ */
+
+#ifndef PM_DEFS_H_
+#define PM_DEFS_H_
+
+/** @name Capabilities for RAM
+ *
+ * @{
+ */
+#define PM_CAP_ACCESS 0x1U
+#define PM_CAP_CONTEXT 0x2U
+#define PM_CAP_WAKEUP 0x4U
+/**@}*/
+
+/**
+ * PM Node ID Enum
+ */
+enum XPmNodeId {
+ NODE_UNKNOWN,
+ NODE_APU,
+ NODE_APU_0,
+ NODE_APU_1,
+ NODE_APU_2,
+ NODE_APU_3,
+ NODE_RPU,
+ NODE_RPU_0,
+ NODE_RPU_1,
+ NODE_PLD,
+ NODE_FPD,
+ NODE_OCM_BANK_0,
+ NODE_OCM_BANK_1,
+ NODE_OCM_BANK_2,
+ NODE_OCM_BANK_3,
+ NODE_TCM_0_A,
+ NODE_TCM_0_B,
+ NODE_TCM_1_A,
+ NODE_TCM_1_B,
+ NODE_L2,
+ NODE_GPU_PP_0,
+ NODE_GPU_PP_1,
+ NODE_USB_0,
+ NODE_USB_1,
+ NODE_TTC_0,
+ NODE_TTC_1,
+ NODE_TTC_2,
+ NODE_TTC_3,
+ NODE_SATA,
+ NODE_ETH_0,
+ NODE_ETH_1,
+ NODE_ETH_2,
+ NODE_ETH_3,
+ NODE_UART_0,
+ NODE_UART_1,
+ NODE_SPI_0,
+ NODE_SPI_1,
+ NODE_I2C_0,
+ NODE_I2C_1,
+ NODE_SD_0,
+ NODE_SD_1,
+ NODE_DP,
+ NODE_GDMA,
+ NODE_ADMA,
+ NODE_NAND,
+ NODE_QSPI,
+ NODE_GPIO,
+ NODE_CAN_0,
+ NODE_CAN_1,
+ NODE_EXTERN,
+ NODE_APLL,
+ NODE_VPLL,
+ NODE_DPLL,
+ NODE_RPLL,
+ NODE_IOPLL,
+ NODE_DDR,
+ NODE_IPI_APU,
+ NODE_IPI_RPU_0,
+ NODE_GPU,
+ NODE_PCIE,
+ NODE_PCAP,
+ NODE_RTC,
+ NODE_LPD,
+ NODE_VCU,
+ NODE_IPI_RPU_1,
+ NODE_IPI_PL_0,
+ NODE_IPI_PL_1,
+ NODE_IPI_PL_2,
+ NODE_IPI_PL_3,
+ NODE_PL,
+ NODE_ID_MAX
+};
+
+/**
+ * PM Reset Line IDs
+ */
+enum XPmReset {
+ XILPM_RESET_PCIE_CFG = 1000,
+ XILPM_RESET_PCIE_BRIDGE,
+ XILPM_RESET_PCIE_CTRL,
+ XILPM_RESET_DP,
+ XILPM_RESET_SWDT_CRF,
+ XILPM_RESET_AFI_FM5,
+ XILPM_RESET_AFI_FM4,
+
[U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
Optionally allow U-Boot to load at the PMU firmware configuration object
into the Power Management Unit (PMU) on Xilinx ZynqMP.
The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.
All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:
*
https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
*
https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357
The load is logged on the console during boot:
U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...
Signed-off-by: Luca Ceresoli
---
Changes RFC v1 -> RFC v2:
- Load the cfg_obj in SPL, not U-Boot proper: this required a complete
reimplementation since we cannot rely on ATF now
- Update and refine the Kconfig option help
Todo:
- don't compile pm_cfg_obj.c from source, load it from a binary file
---
board/xilinx/zynqmp/Kconfig | 26
board/xilinx/zynqmp/Makefile | 5 ++
board/xilinx/zynqmp/pmu_ipc.c | 116 ++
board/xilinx/zynqmp/pmu_ipc.h | 14
board/xilinx/zynqmp/zynqmp.c | 11
5 files changed, 172 insertions(+)
create mode 100644 board/xilinx/zynqmp/pmu_ipc.c
create mode 100644 board/xilinx/zynqmp/pmu_ipc.h
diff --git a/board/xilinx/zynqmp/Kconfig b/board/xilinx/zynqmp/Kconfig
index 7d1f7398c3e9..4201e38571e7 100644
--- a/board/xilinx/zynqmp/Kconfig
+++ b/board/xilinx/zynqmp/Kconfig
@@ -15,4 +15,30 @@ config CMD_ZYNQMP
and authentication feature enabled while generating
BOOT.BIN using Xilinx bootgen tool.
+config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+ string "PMU firmware configuration object to load at runtime"
+ help
+ Path to a PMU firmware configuration object to be built into
+ U-Boot and loaded at runtime by SPL into the PMU firmware.
+
+ The ZynqMP Power Management Unit (PMU) needs a configuration
+ object for most SoC peripherals to work. It can be either
+ hard-coded in the PMUFW or passed at runtime.
+
+ If the configuration object is not hard-coded in the PMU
+ firmware, U-Boot SPL can load it at runtime. To enable this
+ feature set here the file name (absolute path or relative to
+ board/xilinx/zynqmp/). It will be loaded into the PMU firmware by
+ U-Boot SPL during board initialization.
+
+ Note: if your pm_cfg_obj.c is generated by the Xilinx tools,
+ you must remove any linking directives from the
+ XPm_ConfigObject declaration! E.g.:
+
+ -const u32 XPm_ConfigObject[] __attribute__((used,
section(".sys_cfg_data"))) = {
+ +const u32 XPm_ConfigObject[] = {
+
+ Leave this option empty if your PMU firmware has a hard-coded
+ configuration object or you are loading it by any other means.
+
endif
diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
index 80f8ca7e1e4b..0d8f52ecd631 100644
--- a/board/xilinx/zynqmp/Makefile
+++ b/board/xilinx/zynqmp/Makefile
@@ -33,6 +33,11 @@ ifneq ($(call ifdef_any_of, CONFIG_ZYNQMP_PSU_INIT_ENABLED
CONFIG_SPL_BUILD),)
obj-y += $(init-objs)
endif
+ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
+CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ -I$(srctree)/$(src)
+obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o
+endif
+
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
ifndef CONFIG_SPL_BUILD
diff --git a/board/xilinx/zynqmp/pmu_ipc.c b/board/xilinx/zynqmp/pmu_ipc.c
new file mode 100644
index ..6306d33d6f17
--- /dev/null
+++ b/board/xilinx/zynqmp/pmu_ipc.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Inter-Processor Communication with the Platform Management Unit (PMU)
+ * firmware.
+ *
+ * (C) Copyright 2019 Luca Ceresoli
+ * Luca Ceresoli
+ */
+
+#include "pmu_ipc.h"
+#include
+#include
+
+/* IPI bitmasks, register base and register offsets */
+#define IPI_BIT_MASK_APU 0x1
+#define IPI_BIT_MASK_PMU0 0x1
+#define IPI_REG_BASE_APU 0xFF30
+#define IPI_REG_BASE_PMU0 0xFF33
+#define IPI_REG_OFFSET_TRIG 0x00
+#define IPI_REG_OFFSET_OBR0x04
+
+/* IPI mailbox buffer offsets */
+#define IPI_BUF_BASE_APU 0xFF990400
+#define IPI_BUF_OFFSET_TARGET_PMU 0x1C0
+#define IPI_BUF_OFFSET_REQ 0x00
+#define IPI_BUF_OFFSET_RESP0x20
+
+/* Xilinx FSBL sets 8, AT
[U-Boot] [RFC 1/2] arm64: zynqmp: add minimal include files to build a pm_cfg_obj.c
A following commit will allow U-Boot to pass a configuration object to
the ZynqMP PMU firmware. This configuration object is generated by
Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a
few headers with constants definitions.
In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal
version of those headers files:
- pm_defs: a copy of [0], reduced to remove unneeded values
- pmu_global.h: empty file, it is included but not really needed
- xil_types.h: just includes common.h which has all the needed types
[0]
https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h
Signed-off-by: Luca Ceresoli
---
board/xilinx/zynqmp/pm_defs.h| 254 +++
board/xilinx/zynqmp/pmu_global.h | 0
board/xilinx/zynqmp/xil_types.h | 1 +
3 files changed, 255 insertions(+)
create mode 100644 board/xilinx/zynqmp/pm_defs.h
create mode 100644 board/xilinx/zynqmp/pmu_global.h
create mode 100644 board/xilinx/zynqmp/xil_types.h
diff --git a/board/xilinx/zynqmp/pm_defs.h b/board/xilinx/zynqmp/pm_defs.h
new file mode 100644
index ..a339d5ef4fd1
--- /dev/null
+++ b/board/xilinx/zynqmp/pm_defs.h
@@ -0,0 +1,254 @@
+/**
+*
+* Copyright (C) 2015-2018 Xilinx, Inc. All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a copy
+* of this software and associated documentation files (the "Software"), to deal
+* in the Software without restriction, including without limitation the rights
+* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+* copies of the Software, and to permit persons to whom the Software is
+* furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+* XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+* SOFTWARE.
+*
+* Except as contained in this notice, the name of the Xilinx shall not be used
+* in advertising or otherwise to promote the sale, use or other dealings in
+* this Software without prior written authorization from Xilinx.
+*
+**/
+
+/*/
+/**
+ * @file pm_defs.h
+ *
+ * PM Definitions implementation
+ * @addtogroup xpm_apis XilPM APIs
+ * @{
+ */
+
+#ifndef PM_DEFS_H_
+#define PM_DEFS_H_
+
+/** @name Capabilities for RAM
+ *
+ * @{
+ */
+#define PM_CAP_ACCESS 0x1U
+#define PM_CAP_CONTEXT 0x2U
+#define PM_CAP_WAKEUP 0x4U
+/**@}*/
+
+/**
+ * PM Node ID Enum
+ */
+enum XPmNodeId {
+ NODE_UNKNOWN,
+ NODE_APU,
+ NODE_APU_0,
+ NODE_APU_1,
+ NODE_APU_2,
+ NODE_APU_3,
+ NODE_RPU,
+ NODE_RPU_0,
+ NODE_RPU_1,
+ NODE_PLD,
+ NODE_FPD,
+ NODE_OCM_BANK_0,
+ NODE_OCM_BANK_1,
+ NODE_OCM_BANK_2,
+ NODE_OCM_BANK_3,
+ NODE_TCM_0_A,
+ NODE_TCM_0_B,
+ NODE_TCM_1_A,
+ NODE_TCM_1_B,
+ NODE_L2,
+ NODE_GPU_PP_0,
+ NODE_GPU_PP_1,
+ NODE_USB_0,
+ NODE_USB_1,
+ NODE_TTC_0,
+ NODE_TTC_1,
+ NODE_TTC_2,
+ NODE_TTC_3,
+ NODE_SATA,
+ NODE_ETH_0,
+ NODE_ETH_1,
+ NODE_ETH_2,
+ NODE_ETH_3,
+ NODE_UART_0,
+ NODE_UART_1,
+ NODE_SPI_0,
+ NODE_SPI_1,
+ NODE_I2C_0,
+ NODE_I2C_1,
+ NODE_SD_0,
+ NODE_SD_1,
+ NODE_DP,
+ NODE_GDMA,
+ NODE_ADMA,
+ NODE_NAND,
+ NODE_QSPI,
+ NODE_GPIO,
+ NODE_CAN_0,
+ NODE_CAN_1,
+ NODE_EXTERN,
+ NODE_APLL,
+ NODE_VPLL,
+ NODE_DPLL,
+ NODE_RPLL,
+ NODE_IOPLL,
+ NODE_DDR,
+ NODE_IPI_APU,
+ NODE_IPI_RPU_0,
+ NODE_GPU,
+ NODE_PCIE,
+ NODE_PCAP,
+ NODE_RTC,
+ NODE_LPD,
+ NODE_VCU,
+ NODE_IPI_RPU_1,
+ NODE_IPI_PL_0,
+ NODE_IPI_PL_1,
+ NODE_IPI_PL_2,
+ NODE_IPI_PL_3,
+ NODE_PL,
+ NODE_ID_MAX
+};
+
+/**
+ * PM Reset Line IDs
+ */
+enum XPmReset {
+ XILPM_RESET_PCIE_CFG = 1000,
+ XILPM_RESET_PCIE_BRIDGE,
+ XILPM_RESET_PCIE_CTRL,
+ XILPM_RESET_DP,
+ XILPM_RESET_SWDT_CRF,
+ XILPM_RESET_AFI_FM5,
+ XILPM_RESET_AFI_FM4,
+
[U-Boot] [RFC 2/2] arm64: zynqmp: install a PMU firmware config object at runtime
Optionally allow U-Boot to load at the PMU firmware configuration
object into the Power Management Unit (PMU) on Xilinx ZynqMP.
The configuration object is required by the PMU FW to use the SoC. So
far the only way to boot using U-Boot SPL was to hard-code the
configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot proper.
Requires the PM_SET_CONFIGURATION command to be implemented by ARM
Trusted Firmware.
Signed-off-by: Luca Ceresoli
---
arch/arm/mach-zynqmp/include/mach/sys_proto.h | 1 +
board/xilinx/zynqmp/Kconfig | 27 +++
board/xilinx/zynqmp/Makefile | 4 +++
board/xilinx/zynqmp/zynqmp.c | 23
4 files changed, 55 insertions(+)
diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index 385c8825f2f6..1f2c0476ce96 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -22,6 +22,7 @@
#define ZYNQMP_FPGA_AUTH_DDR 1
#define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
+#define ZYNQMP_SIP_SVC_SET_CONFIGURATION 0xC202
#define ZYNQMP_PM_VERSION_MAJOR1
#define ZYNQMP_PM_VERSION_MINOR0
diff --git a/board/xilinx/zynqmp/Kconfig b/board/xilinx/zynqmp/Kconfig
index 7d1f7398c3e9..e9cec5c95470 100644
--- a/board/xilinx/zynqmp/Kconfig
+++ b/board/xilinx/zynqmp/Kconfig
@@ -15,4 +15,31 @@ config CMD_ZYNQMP
and authentication feature enabled while generating
BOOT.BIN using Xilinx bootgen tool.
+config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+ string "PMU firmware configuration object to load at runtime"
+ help
+ Path to a PMU firmware configuration object to be built into
+ U-Boot and loaded at runtime into the PMU firmware.
+
+ The ZynqMP Power Management Unit (PMU) needs a configuration
+ object for most SoC peripherals to work. It can be either
+ hard-coded in the PMUFW or passed at runtime.
+
+ U-Boot can load the configuration object loaded at
+ runtime. To enable this feature set here the file name
+ (absolute path or relative to board/xilinx/zynqmp/). It will
+ be loaded into the PMU firmware at the beginning of U-Boot
+ proper.
+
+ Note: if your pm_cfg_obj.c is generated by the Xilinx tools,
+ you must remove any linking directives from the
+ XPm_ConfigObject declaration! E.g.:
+
+ -const u32 XPm_ConfigObject[] __attribute__((used,
section(".sys_cfg_data"))) = {
+ +const u32 XPm_ConfigObject[] = {
+
+ Leave this option empty if your PMU firmware has a built-in
+ configuration object or you are loading it by any other
+ means.
+
endif
diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
index 80f8ca7e1e4b..5965eff3 100644
--- a/board/xilinx/zynqmp/Makefile
+++ b/board/xilinx/zynqmp/Makefile
@@ -33,6 +33,10 @@ ifneq ($(call ifdef_any_of, CONFIG_ZYNQMP_PSU_INIT_ENABLED
CONFIG_SPL_BUILD),)
obj-y += $(init-objs)
endif
+ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
+CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ -I$(srctree)/$(src)
+endif
+
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
ifndef CONFIG_SPL_BUILD
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 5e1d2116bc32..84fecf5a347f 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -302,6 +302,25 @@ static char *zynqmp_get_silicon_idcode_name(void)
}
#endif
+#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
+#include CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+
+void zynqmp_pmufw_load_config_object(void)
+{
+ u32 *ocm = (u32*) CONFIG_SPL_TEXT_BASE;
+ int err;
+
+ printf("Loading PMUFW cfg obj using OCM @ %p (size %ld)\n",
+ ocm, sizeof(XPm_ConfigObject));
+
+ memcpy(ocm, XPm_ConfigObject, sizeof(XPm_ConfigObject));
+ err = invoke_smc(ZYNQMP_SIP_SVC_SET_CONFIGURATION,
+CONFIG_SPL_TEXT_BASE, 0, 0, 0, NULL);
+ if (err)
+ panic("Cannot load PMUFW configuration object (%d)\n", err);
+}
+#endif // ZYNQMP_LOAD_PM_CFG_OBJ
+
int board_early_init_f(void)
{
int ret = 0;
@@ -316,6 +335,10 @@ int board_early_init_f(void)
if (pm_api_version < ZYNQMP_PM_VERSION)
panic("PMUFW version error. Expected: v%d.%d\n",
ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR);
+
+ #ifdef ZYNQMP_LOAD_PM_CFG_OBJ
+ zynqmp_pmufw_load_config_object();
+ #endif
#endif
#if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 0/2] arm64: zynqmp: pass a PMUFW config object
Hi, a long-standing issue in the ZynqMP users community is the management on the PMU firmware configuration object. The Platform Management Unit (PMU) needs a configuration object (cfg obj) to know how to operate the SoC. When using the "Xilinx workflow", the Xilinx FSBL (First Stage Bootloader) has te SPL role. FSBL has a built-in cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot proper. This is just not implemented in the U-Boot code. The best workaround for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj built-in and self-load it. This approach has some drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuation. It also makes it impossible to change the configuration after boot. This patchset is a first attempt at filling the gap by allowing U-Boot to load the cfg obj firmware at runtime. It adds a Kconfig string option to point to the cfg obj in the form of a C file as produced by Xilinx tools (usually called pm_cfg_obj.c). If the option is non-empty, code is enabled to compile that file in U-Boot proper and to send the configuration to PMUFW early after SPL. This mechanism relies on the underlying EL3 (ARM Trusted Firmware) to implement the SET_CONFIGURATION SMC call. I just sent a trivial pull request [1] to ATF to add this call. With this in place, the path of the cfg obj is U-Boot -> ATF -> PMUFW. This is a rather simple approach that works in many cases, but not all, as pointed out by Michal Simek. Some boards (reportedly zcu100 and ultra96 according to Michal) need the cfg obj loaded in SPL, before applying psu_init. Such boards cannot boot with my patches. Michal also suggested that the cfg obj loading code should be available both in SPL (configured at build time) and in U-Boot proper (loading an object from a file) in order to support different FPGA configuration and partial reconfiguration at runtime. Even with these limitations Michal suggested to send this work as an RFC to start the discussion. These patches are tested on the ZCU106 and UltraZed EV boards. [0] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch [1] https://github.com/ARM-software/arm-trusted-firmware/pull/1850 Luca Luca Ceresoli (2): arm64: zynqmp: add minimal include files to build a pm_cfg_obj.c arm64: zynqmp: install a PMU firmware config object at runtime arch/arm/mach-zynqmp/include/mach/sys_proto.h | 1 + board/xilinx/zynqmp/Kconfig | 27 ++ board/xilinx/zynqmp/Makefile | 4 + board/xilinx/zynqmp/pm_defs.h | 254 ++ board/xilinx/zynqmp/pmu_global.h | 0 board/xilinx/zynqmp/xil_types.h | 1 + board/xilinx/zynqmp/zynqmp.c | 23 ++ 7 files changed, 310 insertions(+) create mode 100644 board/xilinx/zynqmp/pm_defs.h create mode 100644 board/xilinx/zynqmp/pmu_global.h create mode 100644 board/xilinx/zynqmp/xil_types.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fpga: zynqmp: show an error message when FPGA programming fails
When FPGA programming fails, it does so silently, unless debugging
code is enabled. This makes it hard to detect problems in production
environments.
Print the error message unconditionally so the error doesn't go
unnoticed.
Signed-off-by: Luca Ceresoli
---
drivers/fpga/zynqmppl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index c095d5ecaa85..22bfdd8dce61 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -233,7 +233,7 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf,
size_t bsize,
(u32)bsize, 0, ret_payload);
if (ret)
- debug("PL FPGA LOAD fail\n");
+ puts("PL FPGA LOAD fail\n");
return ret;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable
Hi Michal, On 22/06/2018 09:38, Michal Simek wrote: [...] > I have tested it and it looks good. Good, thanks. v2 on its way with the changes you requested. Regards, -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable
Hi Michal, On 22/06/2018 09:38, Michal Simek wrote: > On 20.6.2018 23:00, Luca Ceresoli wrote: >> U-Boot needs to link ps7_init_gpl.c on Zynq or psu_init_gpl.c on >> ZynqMP (PS init for short). The current logic to locate this file for >> both platforms is: >> >> 1. if a board-specific file exists in >> board/xilinx/zynq[mp]/$(CONFIG_DEFAULT_DEVICE_TREE)/ps?_init_gpl.c >> then use it >> 2. otherwise use board/xilinx/zynq/ps?_init_gpl.c >> >> In the latter case the file does not exist in the U-Boot sources and >> must be copied in the source tree from the outside before starting the >> build. This is typical when it is generated from Xilinx tools while >> developing a custom hardware. However making sure that a >> board-specific file is _not_ found (and used) requires some trickery >> such as removing or overwriting all PS init files (e.g.: the current >> meta-xilinx yocto layer [0]). >> >> This generates a few problems: >> >> * if the source tree is shared among different out-of-tree builds, >>they will pollute (and potentially corrupt) each other >> * the source tree cannot be read-only >> * any buildsystem must add a command to copy the PS init file binary >> * overwriting or deleting files in the source tree is ugly as hell >> >> Simplify usage by allowing to pass the path to the desired PS init >> file in kconfig variable XILINX_PS_INIT_FILE. It can be an absolute >> path or relative to $(srctree). If the variable is set, the >> user-specified file will always be used without being copied >> around. If the the variable is left empty, for backward compatibility >> fall back to the old behaviour. >> >> Since the issue is the same for Zynq and ZynqMP, add one kconfig >> variable in a common place and use it for both. >> >> Also use the new kconfig help text to document all the ways to give >> U-Boot the PS init file. >> >> Build-tested with all combinations of: >> - platform: zynq or zynqmp >> - PS init file: from XILINX_PS_INIT_FILE (absolute, relative path, >>non-existing), in-tree board-specific, in board/xilinx/zynq[mp]/ >> - building in-tree, in subdir, in other directory >> >> [0] >> https://github.com/Xilinx/meta-xilinx/blob/b2f74cc7fe5c4881589d5e440a17cb51fc66a7ab/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc#L9 > > Please move this link out of commit message (also fix link above). It is > quite long and almost useless. > >> >> Signed-off-by: Luca Ceresoli >> Cc: Albert Aribaud >> Cc: Michal Simek >> Cc: Nathan Rossi >> --- >> arch/arm/Kconfig | 1 + >> board/xilinx/Kconfig | 41 + >> board/xilinx/zynq/Makefile | 10 +- >> board/xilinx/zynqmp/Makefile | 10 +- >> 4 files changed, 60 insertions(+), 2 deletions(-) >> create mode 100644 board/xilinx/Kconfig >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 22234cde2ab6..e04979d0ef7e 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1441,6 +1441,7 @@ source "board/toradex/colibri_pxa270/Kconfig" >> source "board/vscom/baltos/Kconfig" >> source "board/woodburn/Kconfig" >> source "board/work-microwave/work_92105/Kconfig" >> +source "board/xilinx/Kconfig" >> source "board/xilinx/zynqmp/Kconfig" >> source "board/zipitz2/Kconfig" >> >> diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig >> new file mode 100644 >> index ..aa3fa061edef >> --- /dev/null >> +++ b/board/xilinx/Kconfig >> @@ -0,0 +1,41 @@ >> +# Copyright (c) 2018, Luca Ceresoli >> +# >> +# SPDX-License-Identifier: GPL-2.0 > > Please make this as a first line. > >> + >> +if ARCH_ZYNQ || ARCH_ZYNQMP >> + >> +config XILINX_PS_INIT_FILE >> +string "Zynq/ZynqMP PS init file(s) location" >> +help >> + On Zynq and ZynqMP U-Boot SPL (or U-Boot proper if >> + ZYNQMP_PSU_INIT_ENABLED is set) is responsible for some >> + basic initializations, such as enabling peripherals and >> + configuring pinmuxes. The PS init file (called >> + psu_init_gpl.c on ZynqMP, ps7_init_gpl.c for Zynq-7000) >> + contains the code for such initializations. >> + >> + U-Boot contains PS init files for some boards, but each of >> + them describes only one specific configuration. Users of a >> + different board, or
[U-Boot] [PATCH v2] arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable
U-Boot needs to link ps7_init_gpl.c on Zynq or psu_init_gpl.c on ZynqMP (PS init for short). The current logic to locate this file for both platforms is: 1. if a board-specific file exists in board/xilinx/zynq[mp]/$(CONFIG_DEFAULT_DEVICE_TREE)/ps?_init_gpl.c then use it 2. otherwise use board/xilinx/zynq/ps?_init_gpl.c In the latter case the file does not exist in the U-Boot sources and must be copied in the source tree from the outside before starting the build. This is typical when it is generated from Xilinx tools while developing a custom hardware. However making sure that a board-specific file is _not_ found (and used) requires some trickery such as removing or overwriting all PS init files (e.g.: the current meta-xilinx yocto layer). This generates a few problems: * if the source tree is shared among different out-of-tree builds, they will pollute (and potentially corrupt) each other * the source tree cannot be read-only * any buildsystem must add a command to copy the PS init file binary * overwriting or deleting files in the source tree is ugly as hell Simplify usage by allowing to pass the path to the desired PS init file in kconfig variable XILINX_PS_INIT_FILE. It can be an absolute path or relative to $(srctree). If the variable is set, the user-specified file will always be used without being copied around. If the the variable is left empty, for backward compatibility fall back to the old behaviour. Since the issue is the same for Zynq and ZynqMP, add one kconfig variable in a common place and use it for both. Also use the new kconfig help text to document all the ways to give U-Boot the PS init file. Build-tested with all combinations of: - platform: zynq or zynqmp - PS init file: from XILINX_PS_INIT_FILE (absolute, relative path, non-existing), in-tree board-specific, in board/xilinx/zynq[mp]/ - building in-tree, in subdir, in other directory Signed-off-by: Luca Ceresoli Cc: Albert Aribaud Cc: Michal Simek Cc: Nathan Rossi --- Changes v1 -> v2: - removed link to yocto layer code (Michal) - fixed location of SPDX line (Michal) --- arch/arm/Kconfig | 1 + board/xilinx/Kconfig | 41 + board/xilinx/zynq/Makefile | 10 +- board/xilinx/zynqmp/Makefile | 10 +- 4 files changed, 60 insertions(+), 2 deletions(-) create mode 100644 board/xilinx/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 22234cde2ab6..e04979d0ef7e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1441,6 +1441,7 @@ source "board/toradex/colibri_pxa270/Kconfig" source "board/vscom/baltos/Kconfig" source "board/woodburn/Kconfig" source "board/work-microwave/work_92105/Kconfig" +source "board/xilinx/Kconfig" source "board/xilinx/zynqmp/Kconfig" source "board/zipitz2/Kconfig" diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig new file mode 100644 index ..37bec5fae29d --- /dev/null +++ b/board/xilinx/Kconfig @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Copyright (c) 2018, Luca Ceresoli + +if ARCH_ZYNQ || ARCH_ZYNQMP + +config XILINX_PS_INIT_FILE + string "Zynq/ZynqMP PS init file(s) location" + help + On Zynq and ZynqMP U-Boot SPL (or U-Boot proper if + ZYNQMP_PSU_INIT_ENABLED is set) is responsible for some + basic initializations, such as enabling peripherals and + configuring pinmuxes. The PS init file (called + psu_init_gpl.c on ZynqMP, ps7_init_gpl.c for Zynq-7000) + contains the code for such initializations. + + U-Boot contains PS init files for some boards, but each of + them describes only one specific configuration. Users of a + different board, or needing a different configuration, can + generate custom files using the Xilinx development tools. + + There are three ways to give a PS init file to U-Boot: + + 1. Set this variable to the path, either relative to the +source tree or absolute, where the psu_init_gpl.c or +ps7_init_gpl.c file is located. U-Boot will build this +file. + + 2. If you leave an empty string here, U-Boot will use +board/xilinx/zynq/$(CONFIG_DEFAULT_DEVICE_TREE)/ps7_init_gpl.c +for Zynq-7000, or +board/xilinx/zynqmp/$(CONFIG_DEFAULT_DEVICE_TREE)/psu_init_gpl.c +for ZynqMP. + + 3. If the above file does not exist, U-Boot will use +board/xilinx/zynq/ps7_init_gpl.c for Zynq-7000, or +board/xilinx/zynqmp/psu_init_gpl.c for ZynqMP. This file +is not provided by U-Boot, you have to copy it there +before the build. + +endif diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile index 5a76a26720cd..03ad5f0532ee 100644 --- a/board/xilinx/zynq/Makefile +++ b/board/xilinx/z
[U-Boot] [PATCH] arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable
U-Boot needs to link ps7_init_gpl.c on Zynq or psu_init_gpl.c on ZynqMP (PS init for short). The current logic to locate this file for both platforms is: 1. if a board-specific file exists in board/xilinx/zynq[mp]/$(CONFIG_DEFAULT_DEVICE_TREE)/ps?_init_gpl.c then use it 2. otherwise use board/xilinx/zynq/ps?_init_gpl.c In the latter case the file does not exist in the U-Boot sources and must be copied in the source tree from the outside before starting the build. This is typical when it is generated from Xilinx tools while developing a custom hardware. However making sure that a board-specific file is _not_ found (and used) requires some trickery such as removing or overwriting all PS init files (e.g.: the current meta-xilinx yocto layer [0]). This generates a few problems: * if the source tree is shared among different out-of-tree builds, they will pollute (and potentially corrupt) each other * the source tree cannot be read-only * any buildsystem must add a command to copy the PS init file binary * overwriting or deleting files in the source tree is ugly as hell Simplify usage by allowing to pass the path to the desired PS init file in kconfig variable XILINX_PS_INIT_FILE. It can be an absolute path or relative to $(srctree). If the variable is set, the user-specified file will always be used without being copied around. If the the variable is left empty, for backward compatibility fall back to the old behaviour. Since the issue is the same for Zynq and ZynqMP, add one kconfig variable in a common place and use it for both. Also use the new kconfig help text to document all the ways to give U-Boot the PS init file. Build-tested with all combinations of: - platform: zynq or zynqmp - PS init file: from XILINX_PS_INIT_FILE (absolute, relative path, non-existing), in-tree board-specific, in board/xilinx/zynq[mp]/ - building in-tree, in subdir, in other directory [0] https://github.com/Xilinx/meta-xilinx/blob/b2f74cc7fe5c4881589d5e440a17cb51fc66a7ab/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc#L9 Signed-off-by: Luca Ceresoli Cc: Albert Aribaud Cc: Michal Simek Cc: Nathan Rossi --- arch/arm/Kconfig | 1 + board/xilinx/Kconfig | 41 + board/xilinx/zynq/Makefile | 10 +- board/xilinx/zynqmp/Makefile | 10 +- 4 files changed, 60 insertions(+), 2 deletions(-) create mode 100644 board/xilinx/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 22234cde2ab6..e04979d0ef7e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1441,6 +1441,7 @@ source "board/toradex/colibri_pxa270/Kconfig" source "board/vscom/baltos/Kconfig" source "board/woodburn/Kconfig" source "board/work-microwave/work_92105/Kconfig" +source "board/xilinx/Kconfig" source "board/xilinx/zynqmp/Kconfig" source "board/zipitz2/Kconfig" diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig new file mode 100644 index ..aa3fa061edef --- /dev/null +++ b/board/xilinx/Kconfig @@ -0,0 +1,41 @@ +# Copyright (c) 2018, Luca Ceresoli +# +# SPDX-License-Identifier: GPL-2.0 + +if ARCH_ZYNQ || ARCH_ZYNQMP + +config XILINX_PS_INIT_FILE + string "Zynq/ZynqMP PS init file(s) location" + help + On Zynq and ZynqMP U-Boot SPL (or U-Boot proper if + ZYNQMP_PSU_INIT_ENABLED is set) is responsible for some + basic initializations, such as enabling peripherals and + configuring pinmuxes. The PS init file (called + psu_init_gpl.c on ZynqMP, ps7_init_gpl.c for Zynq-7000) + contains the code for such initializations. + + U-Boot contains PS init files for some boards, but each of + them describes only one specific configuration. Users of a + different board, or needing a different configuration, can + generate custom files using the Xilinx development tools. + + There are three ways to give a PS init file to U-Boot: + + 1. Set this variable to the path, either relative to the +source tree or absolute, where the psu_init_gpl.c or +ps7_init_gpl.c file is located. U-Boot will build this +file. + + 2. If you leave an empty string here, U-Boot will use +board/xilinx/zynq/$(CONFIG_DEFAULT_DEVICE_TREE)/ps7_init_gpl.c +for Zynq-7000, or +board/xilinx/zynqmp/$(CONFIG_DEFAULT_DEVICE_TREE)/psu_init_gpl.c +for ZynqMP. + + 3. If the above file does not exist, U-Boot will use +board/xilinx/zynq/ps7_init_gpl.c for Zynq-7000, or +board/xilinx/zynqmp/psu_init_gpl.c for ZynqMP. This file +is not provided by U-Boot, you have to copy it there +before the build. + +endif diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile index 5a76a26720cd..03ad5f0532ee 100644 --- a/board/xilinx/zynq/
Re: [U-Boot] [PATCH] if_changed: fix error handling
Hi Chris, On 06/06/2018 05:23, Chris Packham wrote: > Hi, > > On Tue, Jun 5, 2018 at 2:08 AM Luca Ceresoli wrote: >> >> The commands in if_changed and if_changed_dep are concatenated with a >> ';', thus any error in any command except the last one will be >> silently ignored. This is particularly relevant for the actual >> payload, cmd_$(1), whose errors should not be unnoticed. >> >> Fix by replacing the ';' with '&&'. >> >> Signed-off-by: Luca Ceresoli >> >> --- >> >> Note: I'm not aware of any situation in which this bug has any visible >> effect. I noticed the problem while working on a different topic, but >> later I did that job in a different way, not involving if_changed >> usages. But this is a bug anyway, so let's fix it. >> --- >> scripts/Kbuild.include | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include >> index 2c7918ad3721..f722f75611df 100644 >> --- a/scripts/Kbuild.include >> +++ b/scripts/Kbuild.include >> @@ -255,16 +255,16 @@ any-pThis is tricky, arereq = $(filter-out >> $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^) >> # Execute command if command has changed or prerequisite(s) are updated. >> # >> if_changed = $(if $(strip $(any-prereq) $(arg-check)), >> \ >> - @set -e; >> \ >> - $(echo-cmd) $(cmd_$(1)); >> \ >> + @set -e; >> \ >> + $(echo-cmd) $(cmd_$(1)) && >> \ >> printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd) >> >> # Execute the command and also postprocess generated .d dependencies file. >> if_changed_dep = $(if $(strip $(any-prereq) $(arg-check) ), >> \ >> - @set -e; >> \ >> - $(echo-cmd) $(cmd_$(1)); >> \ >> - scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > >> $(dot-target).tmp;\ >> - rm -f $(depfile); >> \ >> + @set -e; >> \ >> + $(echo-cmd) $(cmd_$(1)) && >> \ >> + scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp >> && \ >> + rm -f $(depfile) && >> \ >> mv -f $(dot-target).tmp $(dot-target).cmd) >> >> # Usage: $(call if_changed_rule,foo) > > The 'set -e' should cause the sub-shell to exit immediately if any of > the commands fail, regardless of the ';' vs '&&'. Thanks for your comment, it triggered me to go deeper in understanding the issue. Apologies for not having clarified it all in the first place. Actually ';' and '&&' are not treated the same way. The bash manpage states about 'set -e': > The shell does not exit if the command that fails is [...] part of > any command executed in a && or || list except the command following > the final && or || The issue I had initially happened when I wrote something like this: cmd_mkimage = test -r /no/such/file && \ $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \ >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT)) If the 'test' command fails, set -e won't stop the build. But replacing '&&' with ';' makes the build stop immediately as expected. So I guess cmd_mkimage is just meant to be used with ';'. > Assuming I'm wrong above, this patch should probably go to the kbuild > mailing list http://vger.kernel.org/vger-lists.html#linux-kbuild -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] if_changed: fix error handling
The commands in if_changed and if_changed_dep are concatenated with a ';', thus any error in any command except the last one will be silently ignored. This is particularly relevant for the actual payload, cmd_$(1), whose errors should not be unnoticed. Fix by replacing the ';' with '&&'. Signed-off-by: Luca Ceresoli --- Note: I'm not aware of any situation in which this bug has any visible effect. I noticed the problem while working on a different topic, but later I did that job in a different way, not involving if_changed usages. But this is a bug anyway, so let's fix it. --- scripts/Kbuild.include | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 2c7918ad3721..f722f75611df 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -255,16 +255,16 @@ any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^) # Execute command if command has changed or prerequisite(s) are updated. # if_changed = $(if $(strip $(any-prereq) $(arg-check)), \ - @set -e; \ - $(echo-cmd) $(cmd_$(1)); \ + @set -e; \ + $(echo-cmd) $(cmd_$(1)) && \ printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd) # Execute the command and also postprocess generated .d dependencies file. if_changed_dep = $(if $(strip $(any-prereq) $(arg-check) ), \ - @set -e; \ - $(echo-cmd) $(cmd_$(1)); \ - scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\ - rm -f $(depfile);\ + @set -e; \ + $(echo-cmd) $(cmd_$(1)) && \ + scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp && \ + rm -f $(depfile) && \ mv -f $(dot-target).tmp $(dot-target).cmd) # Usage: $(call if_changed_rule,foo) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE
Hi Emmanuel, On 31/05/2018 17:14, Emmanuel Vadot wrote: > On Thu, 31 May 2018 16:28:46 +0200 > Michal Simek wrote: > >> On 31.5.2018 14:58, Luca Ceresoli wrote: >>> The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus >>> forcing it to be a relative path inside the U-Boot source tree. Since >>> the PMUFW is a binary file generated outside of U-Boot, the PMUFW >>> binary must be copied inside the U-Boot source tree before the >>> build. >>> >>> This generates a few problems: >>> >>> * if the source tree is shared among different out-of-tree builds, >>>they will pollute (and potentially corrupt) each other >>> * the source tree cannot be read-only >>> * any buildsystem must add a command to copy the PMUFW binary >>> * putting an externally-generated binary in the source tree is ugly >>>as hell >>> >>> Avoid these problems by accepting an absolute path for >>> PMUFW_INIT_FILE. This would be as simple as removing the "$(srctree)/" >>> prefix, but in order to keep backward compatibility we rather use the >>> shell and readlink to get the absolute path even when starting from a >>> relative path. >>> >>> Tested in the 9 possible combinations of: >>> - PMUFW_INIT_FILE empty, relative or absolute >>> - building in-tree, in subdir, in other directory >>> >>> Signed-off-by: Luca Ceresoli >>> Cc: Michal Simek >>> Cc: Simon Glass >>> --- >>> scripts/Makefile.spl | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >>> index 057389997de6..ef1681ef4bf5 100644 >>> --- a/scripts/Makefile.spl >>> +++ b/scripts/Makefile.spl >>> @@ -168,7 +168,7 @@ MKIMAGEFLAGS_boot.bin = -T zynqimage -R >>> $(srctree)/$(CONFIG_BOOT_INIT_FILE) >>> endif >>> ifdef CONFIG_ARCH_ZYNQMP >>> MKIMAGEFLAGS_boot.bin = -T zynqmpimage -R >>> $(srctree)/$(CONFIG_BOOT_INIT_FILE) \ >>> - -n $(srctree)/$(CONFIG_PMUFW_INIT_FILE) >>> + -n "$(shell cd $(srctree); readlink -m $(CONFIG_PMUFW_INIT_FILE))" >>> endif >>> >>> spl/boot.bin: $(obj)/u-boot-spl.bin FORCE >>> >> >> looks good. >> >> Tom: Do we still have people who build u-boot on BSD system? >> I would like to know if this readlink -m works there. >> >> Thanks, >> Michal >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot > > We don't have -m on FreeBSD and after checking they don't either on > OpenBSD and NetBSD. I just sent v2, where readlink -f is used. However it also uses 'test -r' and 'false', can you confirm those commands portable on BSDs? Thanks, -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE
The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus forcing it to be a relative path inside the U-Boot source tree. Since the PMUFW is a binary file generated outside of U-Boot, the PMUFW binary must be copied inside the U-Boot source tree before the build. This generates a few problems: * if the source tree is shared among different out-of-tree builds, they will pollute (and potentially corrupt) each other * the source tree cannot be read-only * any buildsystem must add a command to copy the PMUFW binary * putting an externally-generated binary in the source tree is ugly as hell Avoid these problems by accepting an absolute path for PMUFW_INIT_FILE. This would be as simple as removing the "$(srctree)/" prefix, but in order to keep backward compatibility we rather use the shell and readlink to get the absolute path even when starting from a relative path. Since 'readlink -f' produces an empty string if the file does not exist, we also add a check to ensure the file configured in PMUFW_INIT_FILE exists. Otherwise the build would exit successfully, but produce a boot.bin without PMUFW as if PMUFW_INIT_FILE were empty. Tested in the 12 possible combinations of: - PMUFW_INIT_FILE empty, relative, absolute, non-existing - building in-tree, in subdir, in other directory Signed-off-by: Luca Ceresoli Cc: Michal Simek Cc: Simon Glass Cc: Emmanuel Vadot --- Changes v1 -> v2: - avoid non-portable 'readlink -m' by adding an explicit check to ensure the file exists - test also the case where PMUFW_INIT_FILE points to a non-existing file --- scripts/Makefile.spl | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 057389997de6..08660878b49e 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -167,8 +167,14 @@ ifdef CONFIG_ARCH_ZYNQ MKIMAGEFLAGS_boot.bin = -T zynqimage -R $(srctree)/$(CONFIG_BOOT_INIT_FILE) endif ifdef CONFIG_ARCH_ZYNQMP +ifneq ($(CONFIG_PMUFW_INIT_FILE),"") +spl/boot.bin: zynqmp-check-pmufw +zynqmp-check-pmufw: FORCE + ( cd $(srctree) && test -r $(CONFIG_PMUFW_INIT_FILE) ) \ + || ( echo "Cannot read $(CONFIG_PMUFW_INIT_FILE)" && false ) +endif MKIMAGEFLAGS_boot.bin = -T zynqmpimage -R $(srctree)/$(CONFIG_BOOT_INIT_FILE) \ - -n $(srctree)/$(CONFIG_PMUFW_INIT_FILE) + -n "$(shell cd $(srctree); readlink -f $(CONFIG_PMUFW_INIT_FILE))" endif spl/boot.bin: $(obj)/u-boot-spl.bin FORCE -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE
Hi Michal, Emmanuel, On 31/05/2018 17:14, Emmanuel Vadot wrote: > On Thu, 31 May 2018 16:28:46 +0200 > Michal Simek wrote: > >> On 31.5.2018 14:58, Luca Ceresoli wrote: >>> The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus >>> forcing it to be a relative path inside the U-Boot source tree. Since >>> the PMUFW is a binary file generated outside of U-Boot, the PMUFW >>> binary must be copied inside the U-Boot source tree before the >>> build. >>> >>> This generates a few problems: >>> >>> * if the source tree is shared among different out-of-tree builds, >>>they will pollute (and potentially corrupt) each other >>> * the source tree cannot be read-only >>> * any buildsystem must add a command to copy the PMUFW binary >>> * putting an externally-generated binary in the source tree is ugly >>>as hell >>> >>> Avoid these problems by accepting an absolute path for >>> PMUFW_INIT_FILE. This would be as simple as removing the "$(srctree)/" >>> prefix, but in order to keep backward compatibility we rather use the >>> shell and readlink to get the absolute path even when starting from a >>> relative path. >>> >>> Tested in the 9 possible combinations of: >>> - PMUFW_INIT_FILE empty, relative or absolute >>> - building in-tree, in subdir, in other directory >>> >>> Signed-off-by: Luca Ceresoli >>> Cc: Michal Simek >>> Cc: Simon Glass >>> --- >>> scripts/Makefile.spl | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >>> index 057389997de6..ef1681ef4bf5 100644 >>> --- a/scripts/Makefile.spl >>> +++ b/scripts/Makefile.spl >>> @@ -168,7 +168,7 @@ MKIMAGEFLAGS_boot.bin = -T zynqimage -R >>> $(srctree)/$(CONFIG_BOOT_INIT_FILE) >>> endif >>> ifdef CONFIG_ARCH_ZYNQMP >>> MKIMAGEFLAGS_boot.bin = -T zynqmpimage -R >>> $(srctree)/$(CONFIG_BOOT_INIT_FILE) \ >>> - -n $(srctree)/$(CONFIG_PMUFW_INIT_FILE) >>> + -n "$(shell cd $(srctree); readlink -m $(CONFIG_PMUFW_INIT_FILE))" >>> endif >>> >>> spl/boot.bin: $(obj)/u-boot-spl.bin FORCE >>> >> >> looks good. >> >> Tom: Do we still have people who build u-boot on BSD system? >> I would like to know if this readlink -m works there. >> >> Thanks, >> Michal >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot > > We don't have -m on FreeBSD and after checking they don't either on > OpenBSD and NetBSD. Ok, then we need a portable version. Thanks for the heads up. The problem with 'readlink -f' is that for a mistyped filename it will call ./tools/mkimage <...> -n "" <...> and exit successfully producing a boot.bin without a pmufw. :( I'll have to find out where to check for file existence, which cannot be done where the readlink is in the present patch. -- Luca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE
The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus forcing it to be a relative path inside the U-Boot source tree. Since the PMUFW is a binary file generated outside of U-Boot, the PMUFW binary must be copied inside the U-Boot source tree before the build. This generates a few problems: * if the source tree is shared among different out-of-tree builds, they will pollute (and potentially corrupt) each other * the source tree cannot be read-only * any buildsystem must add a command to copy the PMUFW binary * putting an externally-generated binary in the source tree is ugly as hell Avoid these problems by accepting an absolute path for PMUFW_INIT_FILE. This would be as simple as removing the "$(srctree)/" prefix, but in order to keep backward compatibility we rather use the shell and readlink to get the absolute path even when starting from a relative path. Tested in the 9 possible combinations of: - PMUFW_INIT_FILE empty, relative or absolute - building in-tree, in subdir, in other directory Signed-off-by: Luca Ceresoli Cc: Michal Simek Cc: Simon Glass --- scripts/Makefile.spl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 057389997de6..ef1681ef4bf5 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -168,7 +168,7 @@ MKIMAGEFLAGS_boot.bin = -T zynqimage -R $(srctree)/$(CONFIG_BOOT_INIT_FILE) endif ifdef CONFIG_ARCH_ZYNQMP MKIMAGEFLAGS_boot.bin = -T zynqmpimage -R $(srctree)/$(CONFIG_BOOT_INIT_FILE) \ - -n $(srctree)/$(CONFIG_PMUFW_INIT_FILE) + -n "$(shell cd $(srctree); readlink -m $(CONFIG_PMUFW_INIT_FILE))" endif spl/boot.bin: $(obj)/u-boot-spl.bin FORCE -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] scripts/check-config.sh: fix "command not found" error handling
scripts/check-config.sh exits successfully and silently without doing
any checks when the 'comm' command is not found.
The problem triggers from the command around line 39:
comm -23 ${suspects} ${ok} >${new_adhoc}
This statement fails when 'comm' is not in $PATH, creating an empty
${new_adhoc} file. But the script continues and the following line,
which is supposed to detect an error:
if [ -s ${new_adhoc} ]; then
will always be false since the file is empty, and the script will exit
successfully as if everything were OK.
The case where 'comm' in not in $PATH is not theoretical. It used to
happen on yocto until a recent fix [0], and still happens on the
current stable branch (rocko).
Fix by setting the errexit flag to exit with error when a statement
fails, so that at least the problem is noticed.
For additional safety also set the nounset flag to detect expansion
errors.
[0]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=fe0b4cb5b48580d4a3f3c0eb82bfa6f1b13801e4
Signed-off-by: Luca Ceresoli <l...@lucaceresoli.net>
---
scripts/check-config.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/check-config.sh b/scripts/check-config.sh
index 267758498b3d..4848ca6e25a5 100755
--- a/scripts/check-config.sh
+++ b/scripts/check-config.sh
@@ -14,6 +14,9 @@
# For example:
# scripts/check-config.sh b/chromebook_link/u-boot.cfg kconfig_whitelist.txt
.
+set -e
+set -u
+
path="$1"
whitelist="$2"
srctree="$3"
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bricked when trying to attach UBI
Luca Ceresoli wrote:
Hi,
I'm Cc'ing the linux-mtd list as well as the authors of the Linux
commits cited below.
For these new readers: I reported a problem with U-Boot 2012.04.01 not
being able to attach an UBI partition in NAND, while Linux (2.6.37) can
attach and repair it.
It looks like an U-Boot bug, but I discovered strange things around the
chip-badblockbits variable (in the NAND code) by comparing the
relevant code in U-Boot and Linux.
Sorry for Cc'ing so many people, but following this issue I was lead
from one subsystem to another (and from U-Boot to Linux).
Previous discussion is here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/149624
Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
Hi Luca,
On 19.12.2012 16:56, Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
...
Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0,
need 1)
Now the device is totally blocked, and power cycling does not change
the result.
have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We
know
ubi recovery needs some ram and 1MiB may be not enough.
Thanks for your suggestion.
Unfortunately this does not seem to be the cause of my problem: I
tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 10) to both (1024 12) and (1024 14), but without any
difference.
Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?
I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!
This swap dates back to:
commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck holger.bru...@keymile.com
Date: Mon Oct 10 13:08:19 2011 +0200
UBI: init eba tables before wl when attaching a device
This fixes that u-boot gets stuck when a bitflip was detected
during ubi part ubi_device. If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.
This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that background thread operations are really executed
we schedule these tasks in place and not as in linux after the
inital
task which schedule this new task is finished.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Stefan Roese s...@denx.de
Signed-off-by: Stefan Roese s...@denx.de
I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!
But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(
I'm Cc:ing the commit author for comments.
Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.
What attach_by_scanning() does in Linux is (abbreviated):
static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi-some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si); /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}
See the two swapped calls.
At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi-avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux: UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0
The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().
After half a day of debugging and an insane amount of printk()s added to
both U-Boot and Linux, I have some more hints to understand the problem.
The two
Re: [U-Boot] Bricked when trying to attach UBI
Hi,
I'm Cc'ing the linux-mtd list as well as the authors of the Linux
commits cited below.
For these new readers: I reported a problem with U-Boot 2012.04.01 not
being able to attach an UBI partition in NAND, while Linux (2.6.37) can
attach and repair it.
It looks like an U-Boot bug, but I discovered strange things around the
chip-badblockbits variable (in the NAND code) by comparing the
relevant code in U-Boot and Linux.
Sorry for Cc'ing so many people, but following this issue I was lead
from one subsystem to another (and from U-Boot to Linux).
Previous discussion is here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/149624
Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
Hi Luca,
On 19.12.2012 16:56, Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
...
Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0,
need 1)
Now the device is totally blocked, and power cycling does not change
the result.
have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We
know
ubi recovery needs some ram and 1MiB may be not enough.
Thanks for your suggestion.
Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 10) to both (1024 12) and (1024 14), but without any
difference.
Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?
I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!
This swap dates back to:
commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck holger.bru...@keymile.com
Date: Mon Oct 10 13:08:19 2011 +0200
UBI: init eba tables before wl when attaching a device
This fixes that u-boot gets stuck when a bitflip was detected
during ubi part ubi_device. If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.
This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that background thread operations are really executed
we schedule these tasks in place and not as in linux after the inital
task which schedule this new task is finished.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Stefan Roese s...@denx.de
Signed-off-by: Stefan Roese s...@denx.de
I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!
But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(
I'm Cc:ing the commit author for comments.
Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.
What attach_by_scanning() does in Linux is (abbreviated):
static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi-some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si); /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}
See the two swapped calls.
At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi-avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux: UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0
The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().
After half a day of debugging and an insane amount of printk()s added to
both U-Boot and Linux, I have some more hints to understand the problem.
The two different results quoted above
[U-Boot] Bricked when trying to attach UBI
Hi all, I am facing a problem with some boards that do not boot after some weeks or months of normal usage, being unable to attach UBI. They do not boot anymore event after a power cycle, in other words they are totally bricked. I don't know exactly what problem UBI has, but it is recoverable by Linux, but apparently not by U-Boot. The boards are DIG297 (dig297 board in mainline U-Boot), based on OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as their unique permanent storage. U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the kernel from UBI, starting with the following commands: echo Booting from nand ... setenv bootargs console=ttyO2,115200n8 mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi) ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip= ubi part nand0,3 ... On bricked devices the output of the ubi part nand0,3 command is: Creating 1 MTD partitions on nand0: 0x0010-0x1000 : mtd=3 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1) Now the device is totally blocked, and power cycling does not change the result. The interesting thing is that if I load Linux (2.6.37 + OMAP patches + board support patches) via TFTP and boot it with bootm, it correctly attaches UBI (fixing any problem it may have) and boots correctly. After that the board is unbricked: U-Boot can boot again normally from NAND. Without the ambition of understanding all UBI internals, I tried to visually inspect the UBI code around the line where the error is produced and compare it to the corresponding Linux sources. They looked extremely similar, so I haven't and obvious hint of why U-Boot and Linux produce different results. I also tried with an updated U-Boot master, but the error is still there. Obviously I have changed nothing in the UBI and MTD code, both in U-Boot and in Linux. Can you suggest a proper way to track the root of the problem, or to bypass it? Big thanks in advance, Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bricked when trying to attach UBI
Hi Andreas, Andreas Bießmann wrote: ... Creating 1 MTD partitions on nand0: 0x0010-0x1000 : mtd=3 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1) Now the device is totally blocked, and power cycling does not change the result. have you tried to increase the malloc arena in u-boot (CONIG_SYS_MALLOC_LEN)? We had errors like this before [1],[2] and [3], maybe others - apparently with another error message, but please give it a try. We know ubi recovery needs some ram and 1MiB may be not enough. Thanks for your suggestion. Unfortunately this does not seem to be the cause of my problem: I tried increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from (1024 10) to both (1024 12) and (1024 14), but without any difference. Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bricked when trying to attach UBI
Hi Andreas,
Andreas Bießmann wrote:
Hi Luca,
On 19.12.2012 16:56, Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
...
Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
Now the device is totally blocked, and power cycling does not change
the result.
have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.
Thanks for your suggestion.
Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 10) to both (1024 12) and (1024 14), but without any
difference.
Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?
I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!
This swap dates back to:
commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck holger.bru...@keymile.com
Date: Mon Oct 10 13:08:19 2011 +0200
UBI: init eba tables before wl when attaching a device
This fixes that u-boot gets stuck when a bitflip was detected
during ubi part ubi_device. If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.
This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that background thread operations are really executed
we schedule these tasks in place and not as in linux after the inital
task which schedule this new task is finished.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Stefan Roese s...@denx.de
Signed-off-by: Stefan Roese s...@denx.de
I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!
But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(
I'm Cc:ing the commit author for comments.
Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.
What attach_by_scanning() does in Linux is (abbreviated):
static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi-some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si); /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}
See the two swapped calls.
At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi-avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux: UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0
The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
