From 2bf4f763e6e7a3a65e60decc6d4fed6fdbf1010a Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Mon, 14 Sep 2020 14:47:21 +0200 Subject: doc: board: xilinx: zynq.rst: Update zynq documentation - Correct location of BSP code - Remove TODO which is done already Signed-off-by: Michal Simek --- doc/board/xilinx/zynq.rst | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/board/xilinx/zynq.rst b/doc/board/xilinx/zynq.rst index f564434b69c..438912fe42c 100644 --- a/doc/board/xilinx/zynq.rst +++ b/doc/board/xilinx/zynq.rst @@ -83,7 +83,7 @@ Mainline status --------------- - Added basic board configurations support. -- Added zynq u-boot bsp code - arch/arm/cpu/armv7/zynq +- Added zynq u-boot bsp code - arch/arm/mach-zynq - Added zynq boards named - zc70x, zed, microzed, zc770_xm010/xm011/xm012/xm013 - Added zynq drivers: @@ -99,11 +99,6 @@ Mainline status - Added basic FDT support for zynq boards - d-cache support for zynq_gem.c -TODO ----- - -Add FDT support on individual drivers - * [1] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm * [2] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm * [3] http://zedboard.org/product/zedboard -- cgit v1.3.1 From 4286f32a4eb85c60c5da7ad4211e5aeb71969e21 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Wed, 16 Sep 2020 15:16:45 +0200 Subject: doc: board: xilinx: Update links to DT binding docs Several drivers have been added without updating documentation. And also some dt bindings have been moved to yaml. Signed-off-by: Michal Simek --- doc/board/xilinx/xilinx.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/board/xilinx/xilinx.rst b/doc/board/xilinx/xilinx.rst index f6ea5dbe215..8c9afb482d6 100644 --- a/doc/board/xilinx/xilinx.rst +++ b/doc/board/xilinx/xilinx.rst @@ -10,18 +10,28 @@ kernel. * ata - Documentation/devicetree/bindings/ata/ahci-ceva.txt +* clock + - Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt +* firmware + - Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt +* fpga + - Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt * gpio - Documentation/devicetree/bindings/gpio/gpio-xilinx.txt - Documentation/devicetree/bindings/gpio/gpio-zynq.txt * i2c - - Documentation/devicetree/bindings/i2c/i2c-xiic.txt - - Documentation/devicetree/bindings/i2c/i2c-cadence.txt + - Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml + - Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml * mmc - - Documentation/devicetree/bindings/mmc/arasan,sdhci.txt + - Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml * net - Documentation/devicetree/bindings/net/macb.txt - Documentation/devicetree/bindings/net/xilinx_axienet.txt - Documentation/devicetree/bindings/net/xilinx_emaclite.txt +* nvmem + - Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt +* power + - Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt * serial - Documentation/devicetree/bindings/serial/cdns,uart.txt - Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt -- cgit v1.3.1 From bbda59ed418a1a17571eaf9cce8d8ed0b5441f61 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Wed, 16 Sep 2020 15:16:37 +0200 Subject: doc: board: xilinx: Add documentation for ZynqMP Add missing documentation for Xilinx ZynqMP configuration with steps how to configure it and run it. Signed-off-by: Michal Simek --- doc/board/xilinx/index.rst | 1 + doc/board/xilinx/zynqmp.rst | 115 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100644 doc/board/xilinx/zynqmp.rst (limited to 'doc') diff --git a/doc/board/xilinx/index.rst b/doc/board/xilinx/index.rst index 47f09290af0..e9560f208fb 100644 --- a/doc/board/xilinx/index.rst +++ b/doc/board/xilinx/index.rst @@ -8,3 +8,4 @@ Xilinx xilinx zynq + zynqmp diff --git a/doc/board/xilinx/zynqmp.rst b/doc/board/xilinx/zynqmp.rst new file mode 100644 index 00000000000..a035cff1a5b --- /dev/null +++ b/doc/board/xilinx/zynqmp.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. (C) Copyright 2020 Xilinx, Inc. + +ZYNQMP +====== + +About this +---------- + +This document describes the information about Xilinx Zynq UltraScale+ MPSOC +U-Boot support. Core support is available in arch/arm/mach-zynqmp folder. + +ZynqMP boards +------------- + +* zcu100 (ultra96 v1), zcu102, zcu104, zcu106 - Evaluation boards +* zc1232 - Characterization boards +* zcu111, zcu208, zcu216 - RFSOC evaluation boards +* zcu1254, zcu1275, zcu1285 - RFSOC characterization boards +* a2197 - System Controller on Versal boards +* mini - Mini U-Boot running out of OCM +* zc1751 - Characterization Processor boards + - zc1751-xm015-dc1 + - zc1751-xm016-dc2 + - zc1751-xm017-dc3 + - zc1751-xm018-dc4 + - zc1751-xm019-dc5 + +Building +-------- + +Configure and build for zcu102 board:: + + $ source arm64 toolchain + $ export DEVICE_TREE=zynqmp-zcu102-revA + $ make xilinx_zynqmp_virt_defconfig + $ make + +U-Boot SPL flow +--------------- + +For getting U-Boot SPL flow up and running it is necessary to do some additional +steps because booting device requires external images which are not the part of +U-Boot repository. + +PMU firmware +^^^^^^^^^^^^ +The Platform Management Unit (PMU) RAM can be loaded with a firmware (PMU +Firmware) at run-time and can be used to extend or customize the functionality +of PMU. The PMU firmware is the part of boot image (boot.bin) and it is +automatically loaded by BootROM. boot.bin can be directly generated by mkimage +tool as the part of make. If you want to create boot.bin with PMU Firmware +include please point CONFIG_PMUFW_INIT_FILE to PMU firmware binary. For example::: + + CONFIG_PMUFW_INIT_FILE="/pmu.bin" + +If you see below message you need to load PMU Firmware:: + + PMUFW is not found - Please load it! + +The second external blob is PMU Configuration object which is object which is +passed from U-Boot SPL to PMU Firmware for initial system configuration. PMU +configuration object is the part of U-Boot SPL image. For pointing to this +object please use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE symbol. For example::: + + CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="/pmu_obj.bin" + + +PMU configuration object +^^^^^^^^^^^^^^^^^^^^^^^^ + +Object can be obtain in several ways. The easiest way is to take pm_cfg_obj.c +from SDK/Vitis design and build it::: + + $ git clone https://github.com/Xilinx/embeddedsw.git + $ export EMBEDDED_SW=$PWD/embeddedsw + $ gcc -c pm_cfg_obj.c -I ${EMBEDDED_SW}/lib/bsp/standalone/src/common/ -I ${EMBEDDED_SW}/lib/sw_services/xilpm/src/zynqmp/client/common/ + $ objcopy -O binary pm_cfg_obj.o pmu_obj.bin + +The second way is to use tools/zynqmp_pm_cfg_obj_convert.py. For more +information about this tool please run it with -h parameter. + +The third way is to extract it from Xilinx FSBL elf file. Object is starting at +XPm_ConfigObject symbol. + + +Arm Trusted Firmware (ATF) +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +U-Boot itself can run from EL3 to EL1. Without ATF U-Boot runs in EL3. Boot flow +is U-Boot SPL->U-Boot in EL3. When ATF is used U-Boot normally runs in EL2. Boot +flow is U-Boot SPL->ATF->U-Boot in EL2. As the part of build process u-boot.itb +is generated. When BL31 shell variable is present u-boot.itb is generated with +ATF included. You can point to it by::: + + $ export BL31=/bl31.bin + +Flashing +-------- + +SD Card +^^^^^^^ + +To write an image that boots from a SD card first create a FAT32 partition +and a FAT32 filesystem on the SD card:: + + sudo fdisk /dev/sdx + sudo mkfs.vfat -F 32 /dev/sdx1 + +Mount the SD card and copy the SPL and U-Boot to the root directory of the +SD card:: + + sudo mount -t vfat /dev/sdx1 /mnt + sudo cp spl/boot.bin /mnt + sudo cp u-boot.itb /mnt -- cgit v1.3.1 From 0d4e6a2d3b39437d6bf5e4b07c442af7ace805d2 Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Mon, 14 Sep 2020 15:00:06 +0200 Subject: doc: board: xilinx: Add documentation for ZynqMP R5 Add missing documentation for Xilinx ZynqMP R5 configuration with steps how to run it. Signed-off-by: Michal Simek --- doc/board/xilinx/index.rst | 1 + doc/board/xilinx/zynqmp-r5.rst | 137 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+) create mode 100644 doc/board/xilinx/zynqmp-r5.rst (limited to 'doc') diff --git a/doc/board/xilinx/index.rst b/doc/board/xilinx/index.rst index e9560f208fb..2e31fe3f3a4 100644 --- a/doc/board/xilinx/index.rst +++ b/doc/board/xilinx/index.rst @@ -9,3 +9,4 @@ Xilinx xilinx zynq zynqmp + zynqmp-r5 diff --git a/doc/board/xilinx/zynqmp-r5.rst b/doc/board/xilinx/zynqmp-r5.rst new file mode 100644 index 00000000000..2cd368b0308 --- /dev/null +++ b/doc/board/xilinx/zynqmp-r5.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. (C) Copyright 2020 Xilinx, Inc. + +ZYNQMP-R5 +========= + +About this +---------- + +This document describes the information about Xilinx Zynq UltraScale+ MPSOC +U-Boot Cortex R5 support. + +ZynqMP R5 boards +---------------- + +* zynqmp-r5 - U-Boot running on RPU Cortex-R5 + +Building +-------- + +configure and build armv7 toolchain:: + + $ make xilinx_zynqmp_r5_defconfig + $ make + +Notes +^^^^^ + +Output fragment is u-boot. + +Loading +------- + +ZynqMP R5 U-Boot was created for supporting loading OS on RPU. There are two +ways how to start U-Boot on R5. + +Bootgen +^^^^^^^ + +The first way is to use Xilinx FSBL (First stage +bootloader) to load u-boot and start it. The following bif can be used for boot +image generation via Xilinx bootgen utility:: + + + the_ROM_image: + { + [bootloader,destination_cpu=r5-0] fsbl_rpu.elf + [destination_cpu=r5-0]u-boot.elf + } + +Bootgen command for building boot.bin:: + + bootgen -image .bif -r -w -o i boot.bin + + +U-Boot cpu command +^^^^^^^^^^^^^^^^^^ + +The second way to load U-Boot to Cortex R5 is from U-Boot running on A53 as is +visible from the following log:: + + U-Boot SPL 2020.10-rc4-00090-g801b3d5c5757 (Sep 15 2020 - 14:07:24 +0200) + PMUFW: v1.1 + Loading new PMUFW cfg obj (2024 bytes) + EL Level: EL3 + Multiboot: 0 + Trying to boot from MMC2 + spl: could not initialize mmc. error: -19 + Trying to boot from MMC1 + spl_load_image_fat_os: error reading image u-boot.bin, err - -2 + NOTICE: ATF running on XCZU7EG/EV/silicon v4/RTL5.1 at 0xfffea000 + NOTICE: BL31: v2.2(release):v2.2-614-ged9dc512fb9c + NOTICE: BL31: Built : 09:32:09, Mar 13 2020 + + + U-Boot 2020.10-rc4-00090-g801b3d5c5757 (Sep 15 2020 - 14:07:24 +0200) + + Model: ZynqMP ZCU104 RevC + Board: Xilinx ZynqMP + DRAM: 2 GiB + PMUFW: v1.1 + EL Level: EL2 + Chip ID: zu7e + WDT: Started with servicing (60s timeout) + NAND: 0 MiB + MMC: mmc@ff170000: 0 + Loading Environment from FAT... *** Warning - bad CRC, using default environment + + In: serial + Out: serial + Err: serial + Bootmode: LVL_SHFT_SD_MODE1 + Reset reason: SOFT + Net: + ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id + eth0: ethernet@ff0e0000 + Hit any key to stop autoboot: 0 + ZynqMP> setenv autoload no + ZynqMP> dhcp + BOOTP broadcast 1 + DHCP client bound to address 192.168.0.167 (8 ms) + ZynqMP> tftpboot 20000000 192.168.0.105:u-boot-r5-2.elf + Using ethernet@ff0e0000 device + TFTP from server 192.168.0.105; our IP address is 192.168.0.167 + Filename 'u-boot-r5-2.elf'. + Load address: 0x20000000 + Loading: ################################################################# + ################################################################# + ################################################################# + ################################################################# + ################################################################# + ################################################################# + ################ + 376 KiB/s + done + Bytes transferred = 2075464 (1fab48 hex) + ZynqMP> setenv autostart no + ZynqMP> bootelf -p 20000000 + ZynqMP> cpu 4 release 10000000 lockstep + Using TCM jump trampoline for address 0x10000000 + R5 lockstep mode + ZynqMP> + +Then on second uart you can see U-Boot up and running on R5:: + + U-Boot 2020.10-rc4-00071-g7045622cc9ba (Sep 16 2020 - 13:38:53 +0200) + + Model: Xilinx ZynqMP R5 + DRAM: 512 MiB + MMC: + In: serial@ff010000 + Out: serial@ff010000 + Err: serial@ff010000 + Net: No ethernet found. + ZynqMP r5> + +Please make sure MIO pins for uart are properly configured to see output. -- cgit v1.3.1 From caa7fc2c57750f323d53aef38c7ee2e01898c4ba Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Thu, 3 Sep 2020 11:24:28 +0200 Subject: spl: Use standard FIT entries SPL is creating fit-images DT node when loadables are recorded in selected configuration. Entries which are created are using entry-point and load-addr property names. But there shouldn't be a need to use non standard properties because entry/load are standard FIT properties. But using standard FIT properties enables option to use generic FIT functions to descrease SPL size. Here is result for ZynqMP virt configuration: xilinx_zynqmp_virt: spl/u-boot-spl:all -82 spl/u-boot-spl:rodata -22 spl/u-boot-spl:text -60 The patch causes change in run time fit image record. Before: fit-images { uboot { os = "u-boot"; type = "firmware"; size = <0xfd520>; entry-point = <0x8000000>; load-addr = <0x8000000>; }; }; After: fit-images { uboot { os = "u-boot"; type = "firmware"; size = <0xfd520>; entry = <0x8000000>; load = <0x8000000>; }; }; Replacing calling fdt_getprop_u32() by fit_image_get_entry/load() also enables support for reading entry/load properties recorded in 64bit format. Signed-off-by: Michal Simek Reviewed-by: Simon Glass --- common/fdt_support.c | 4 +-- common/spl/spl_atf.c | 7 ++-- common/spl/spl_fit.c | 8 ++++- common/spl/spl_opensbi.c | 8 ++--- doc/uImage.FIT/howto.txt | 84 ++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 100 insertions(+), 11 deletions(-) (limited to 'doc') diff --git a/common/fdt_support.c b/common/fdt_support.c index a565b470f81..b8a8768a214 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -616,9 +616,9 @@ int fdt_record_loadable(void *blob, u32 index, const char *name, * However, spl_fit.c is not 64bit safe either: i.e. we should not * have an issue here. */ - fdt_setprop_u32(blob, node, "load-addr", load_addr); + fdt_setprop_u32(blob, node, "load", load_addr); if (entry_point != -1) - fdt_setprop_u32(blob, node, "entry-point", entry_point); + fdt_setprop_u32(blob, node, "entry", entry_point); fdt_setprop_u32(blob, node, "size", size); if (type) fdt_setprop_string(blob, node, "type", type); diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c index b54b4f0d22e..9bd25f6b32c 100644 --- a/common/spl/spl_atf.c +++ b/common/spl/spl_atf.c @@ -132,10 +132,11 @@ static int spl_fit_images_find(void *blob, int os) uintptr_t spl_fit_images_get_entry(void *blob, int node) { ulong val; + int ret; - val = fdt_getprop_u32(blob, node, "entry-point"); - if (val == FDT_ERROR) - val = fdt_getprop_u32(blob, node, "load-addr"); + ret = fit_image_get_entry(blob, node, &val); + if (ret) + ret = fit_image_get_load(blob, node, &val); debug("%s: entry point 0x%lx\n", __func__, val); return val; diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index fd6086a65c3..f5109e86d14 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -332,9 +332,15 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector, } if (image_info) { + ulong entry_point; + image_info->load_addr = load_addr; image_info->size = length; - image_info->entry_point = fdt_getprop_u32(fit, node, "entry"); + + if (!fit_image_get_entry(fit, node, &entry_point)) + image_info->entry_point = entry_point; + else + image_info->entry_point = FDT_ERROR; } return 0; diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c index 14f335f75f0..41e0746bb01 100644 --- a/common/spl/spl_opensbi.c +++ b/common/spl/spl_opensbi.c @@ -61,11 +61,9 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image) } /* Get U-Boot entry point */ - uboot_entry = fdt_getprop_u32(spl_image->fdt_addr, uboot_node, - "entry-point"); - if (uboot_entry == FDT_ERROR) - uboot_entry = fdt_getprop_u32(spl_image->fdt_addr, uboot_node, - "load-addr"); + ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node, &uboot_entry); + if (ret) + ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, &uboot_entry); /* Prepare obensbi_info object */ opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE; diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt index 8592719685e..019dda24a08 100644 --- a/doc/uImage.FIT/howto.txt +++ b/doc/uImage.FIT/howto.txt @@ -66,6 +66,90 @@ can point to a script which generates this image source file during the build process. It gets passed a list of device tree files (taken from the CONFIG_OF_LIST symbol). +The SPL also records to a DT all additional images (called loadables) which are +loaded. The information about loadables locations is passed via the DT node with +fit-images name. + +Loadables Example +----------------- +Consider the following case for an ARM64 platform where U-Boot runs in EL2 +started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). + +/dts-v1/; + +/ { + description = "Configuration to load ATF before U-Boot"; + + images { + uboot { + description = "U-Boot (64-bit)"; + data = /incbin/("u-boot-nodtb.bin"); + type = "firmware"; + os = "u-boot"; + arch = "arm64"; + compression = "none"; + load = <0x8 0x8000000>; + entry = <0x8 0x8000000>; + hash { + algo = "md5"; + }; + }; + atf { + description = "ARM Trusted Firmware"; + data = /incbin/("bl31.bin"); + type = "firmware"; + os = "arm-trusted-firmware"; + arch = "arm64"; + compression = "none"; + load = <0xfffea000>; + entry = <0xfffea000>; + hash { + algo = "md5"; + }; + }; + fdt_1 { + description = "zynqmp-zcu102-revA"; + data = /incbin/("arch/arm/dts/zynqmp-zcu102-revA.dtb"); + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + load = <0x100000>; + hash { + algo = "md5"; + }; + }; + }; + configurations { + default = "config_1"; + + config_1 { + description = "zynqmp-zcu102-revA"; + firmware = "atf"; + loadables = "uboot"; + fdt = "fdt_1"; + }; + }; +}; + +In this case the SPL records via fit-images DT node the information about +loadables U-Boot image. + +ZynqMP> fdt addr $fdtcontroladdr +ZynqMP> fdt print /fit-images +fit-images { + uboot { + os = "u-boot"; + type = "firmware"; + size = <0x001017c8>; + entry = <0x00000008 0x08000000>; + load = <0x00000008 0x08000000>; + }; +}; + +As you can see entry and load properties are 64bit wide to support loading +images above 4GB (in past entry and load properties where just 32bit). + + Example 1 -- old-style (non-FDT) kernel booting ----------------------------------------------- -- cgit v1.3.1