05-05-2017 05:53 AM
I just tried switching from PetaLinux 2016.4 to 2017.1 for my ZU3EG ES1 board. Unfortunately the boot process is stopped with the following error message:
zynqmp_clk_get_peripheral_rate mio read fail
Searching around, this error seems to originate from the ZynqMP Clock driver in u-boot.
This driver was also configured for the working 2016.4 build and according to the official git repository there weren't any changes between 2016.4. and 2017.1 (but apparently this error was degraded to a warning in the current master branch).
Also I kept the u-boot configuration as identical as possible, so I don't really know what's the problem here. Removing this driver is also no solution as u-boot doesn't want to boot without it.
05-06-2017 04:12 AM
I have narrowed it down a little further. I inserted some debugging code into u-boot to find out which clock fails. It apparently is uart0_ref, which is also the first call of zynqmp_clk_get_peripheral_rate().
Looking at the device tree generated with PetaLinux 2017.1, I can see that actually all the clocks for all the peripherals changed. I suppose this might be the reason, but I don't know why this is happening.
05-09-2017 08:45 AM
05-09-2017 09:11 AM
I have made some good progress on this problem but still don't have a bootable version. The core problem was this:
The device tree generated by 2017.1 always includes zynqmp-clk-ccf.dtsi instead of zynqmp-clk.dtsi for obtaining its clock definitions. This requires the common clock framework, which seems to only be available if the PMU-firmware is loaded. I was not using a PMU firmware as I was unable to get the board to boot with it. This seems to be a known problem and was covered in AR68522.
Version 2016.4 did not use the ccf clocks, so everything worked. I tried to apply the work around from AR68522 to build a working PMU firmware. Now the boot process gets as far as this:
NOTICE: ATF running on XCZU3EG/silicon v2/RTL5.1 at 0xfffea000, with PMU firmware NOTICE: BL31: Secure code at 0x60000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v1.3(release):7d1a673 NOTICE: BL31: Built : 14:42:17, May 9 2017 U-Boot 2017.01 (May 09 2017 - 16:56:17 +0200) Xilinx ZynqMP ZCU102 revB I2C: ready DRAM: 2 GiB EL Level:<9>EL2 Chip ID:<9>xczu3eg MMC: SF: Detected n25q256a with page size 512 Bytes, erase size 128 KiB, total 64 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial initcall sequence 000000007ff93180 failed at call 00000000080028fc (err=-22) ### ERROR ### Please RESET the board ###
Looking at the u-boot.map file, the failed init call was board_late_init in zynqmp.c. This function can only fail if the boot mode cannot be read from mmio. So, that's where I'm stuck now.
09-13-2017 09:22 AM
Did you remove the whole components/bootloader/zynqmp_fsbl directory and rebuild? What version of petalinux?
I tried loading the stock files from xilinx rdf0421-zcu102-base-trd-2017-1 bsp via jtag and got this error. But it booted fine with the same binaries loaded onto sd card. Looks like I need to open an SR.
02-01-2018 08:22 PM
I just received a brand new rev1.1 board, and am having the same issue:
zynqmp_clk_get_peripheral_rate mio read fail
I am working through the U1209, Embedded Design tutorial, and have not been successful in getting a Linux boot with any of the methods. The closest I have come is using the SD card method. I get all the way to asking for the user and password, but I cannot type anything.
with every other method, I get the zynqmp_clk_get_peripheral_rate mio read fail message on the terminal connected to UART0. The "hello world" meesage is coming out on R5_0 on UART1.
I do not understand enough about the whole system to do the "fix" mentioned above.
02-01-2018 08:57 PM
I have a theory that my hdf that I based my uboot images on was not correct. I am going to try to carefully repeat all the steps to regenerate them (both SD and flash) and see if my problem goes away.
05-07-2018 07:29 PM
FWIW I ran into the same "zynqmp_clk_get_peripheral_rate mio read fail" error on a ZCU106 using 2018.1.
I was able to work around it by making debug builds of the FSBL and PMU firmware. Here's the patch in case anyone finds it useful in the future...
diff --git a/recipes-bsp/fsbl/fsbl_git.bb b/recipes-bsp/fsbl/fsbl_git.bb index b9ec7e0..1fbb157 100644 --- a/recipes-bsp/fsbl/fsbl_git.bb +++ b/recipes-bsp/fsbl/fsbl_git.bb @@ -10,7 +10,9 @@ COMPATIBLE_MACHINE_zynqmp = "zynqmp" XSCTH_APP_COMPILER_FLAGS_append_zcu102-zynqmp = " -DXPS_BOARD_ZCU102" XSCTH_APP_COMPILER_FLAGS_append_zcu106-zynqmp = " -DXPS_BOARD_ZCU106" -XSCTH_COMPILER_DEBUG_FLAGS = "-O2 -DFSBL_DEBUG_INFO" +# XSCTH_COMPILER_DEBUG_FLAGS = "-O2 -DFSBL_DEBUG_INFO" +XSCTH_COMPILER_DEBUG_FLAGS = "-O2 -DFSBL_DEBUG_INFO -DFSBL_DEBUG_DETAILED" +XSCTH_BUILD_DEBUG = "1" XSCTH_APP_zynq = "Zynq FSBL" XSCTH_APP_zynqmp = "Zynq MP FSBL"