DaleD

Well, just to be clear, about the only thing petalinux-boot is good for is booting via the FSBL. And that will expect U-Boot to bring everything in off the SD or eMMC, so you'll have to have that in place after the FSBL completes its task. For whatever reason, the size of what JTAG boot can process is limited to about the FSBL only. After that, it is like a real system boot. So if it is a DDR problem, look at the FSBL, or for other things look at U-Boot configuration and/or the device tree. In the end, I did not find petalinux-boot useful. I just programmed an SD card with a build that had printk or equivalent statements that were designed to debug the boot process. Similarly, trying to debug the kernel devolved into using petalinux-devtool and patching the kernel to insert dev_info calls to put debug information into the boot log. I've had a rough year with this. Wishing you better than I've experienced.

So for my board, the DDR configuration was set in the Vivado project for the FPGA. That's under the "Recustomize-IP" for the ZynqMP block, DDR Configuration. When the Vivado project exports the .xsa file (hardware handoff) to the PetaLinux project, I bring it in with petalinux-config --get-hw-description xxx.xsa --silentconfig. That generates DDR initialization code for the FSBL. If you are trying to reproduce the Digilent example, look at how they configured the DDR in the Digilent Vivado project. I did not realize at first how much the FSBL needs to know about the FPGA project, because it is initializing DDR, power domains, and other things that Linux does not really know about. Unfortunately, my DDR configuration just worked. So I am not an expert at debugging this part of the board bring-up.

Well, I'm only a year in. But I don't know of a way to go to just Yocto. I'm having some offline discussions with people I found online about whether this is really possible or not. For now, I am resigning myself to using a version of PetaLinux that is working for me. It took several tries to settle on 2023.2. I never ported the Genesys design to 2023.2, but I did find the Digilent design a useful learning step to come up to speed with the out of box project. But in the end, I had to start from scratch to bring up our custom board. Learn what you can from the example projects. If you can find someone that did something similar, work with them. Otherwise, it's a lot of learning the hard way. I'm sorry I don't have better advice. A second thought: I did bring up Yocto-only examples for the BeagleBone Black, for example, just to get some of the Yocto concepts down. This did not directly help, but separated some of the Yocto learning from bringing my SoC FPGA-based board up. It also helped me learn how PetaLinux is both similar and different from a pure Yocto build.

Yes and no. I think the short answer is that there is a lot wrong with PetaLinux 2020.1, and JTAG boot appears to only partly work. In fact, I started using PetaLinux 2020.2 to give more petalinux-boot functionality. This was from a long time ago, but what I think I remember is that 2020.2 allowed me to do a minimal boot through JTAG (FSBL), and a kernel-only boot in QEMU (--prebuilt 2). This was at least more than 2020.1 could do properly. Part of the problem was that I was new to both Yocto and PetaLinux. In my opinion, PetaLinux hides a lot of Yocto from the user, and actually makes it harder to get started, because there are much fewer high quality resources for getting started in a meaningful way. We used our Digilent board to get started with software that would eventually run on our custom board, but found that there was a lot of learning to do to bring up our board after being able to reproduce the Digilent out of box examples. Fast-forward to 2024, and I've learned a lot, and the tools have improved somewhat. I currently use PetaLinux 2023.2. I created a template PetaLinux project based on zynqmp, and added our board-specific recipes to meta-user. When our board didn't boot, we found that there were a couple of issues with FPGA configuration, and we required some FSBL, U-Boot, and kernel patches to support our board. All of these required a lot of time learning Yocto, PetaLinux, the FSBL, U-Boot, and kernel source code. Every version of PetaLinux is buggy. Some of that is weird stuff introduced by Xilinx, and some of that comes along as Yocto baggage. Having said that, I find 2023.2 *so* much better than 2020.x. I still get burned by Yocto oddities, like recipes that don't get built because Xilinx or I used "SRC_URI +=" instead of "SRC_URI:append", or other odd stuff.

I was clearly confusing the Ultrascale+ PMU and the Digilent AtMega PMCU here! The Digilent Reference Manual for the board talks about the PMCU interface.

I have a custom FPGA design and OS built in PetaLinux 2020.1. I am attaching an Analog Devices ADC board via the FMC connector. On boot, the red PMCU LED is blinking: long blink, short pause, short blink, long pause -- the reference manual for the GenesysZU lists this as a SYZYGY or FMC fault. We have nothing on a SYZYGY connector, so assuming this is an FMC fault. The reference manual shows a serial port between the PMU and PS, and a protocol to read registers for more information in PMU register 0x70. Is there a Digilent demo application for the purpose of reading PMU registers? I'm having trouble finding this interface in the Xilinx documentation, can you point me to it? -- UPDATE: It looks like there is a device /sys/firmware/zynqmp/config_reg that gives access to registers in user space. And it looks like the PMU_GLOBAL registers are mapped starting at 0x00ffd80000, according to UG1087, UltraScale+ Register Reference. But, # echo 0xffd80070 > /sys/firmware/zynqmp/config_reg # cat /sys/firmware/zynqmp/config_reg 0x0 gives 0 (no error). Is 0x70 the right offset? I'm having trouble making sense of this.

The first and third methods work exactly as before. The second method hangs. If I program an SD card, it boots fine. So is there something about the board design that QEMU doesn't like?

I built the OOB project from GitHub https://github.com/Digilent/Genesys-ZU release tag 3eg/oob/release/v2.1 with PetaLinux 2020.1. While the resulting image boots on the board when programmed on an SD card, attempting to issue petalinux-boot --qemu --kernel results in a boot that does not progress beyond U-boot (log attached). One error in the log is "Could not get PHY for eth0: addr 15". Do the patches in meta-user/recipes-bsp/u-boot or elsewhere conflict with QEMU? Is there something else I need to configure to allow QEMU to boot? As an extra data point, I created a brand new petalinux-project without the BSP in 2020.1, and was able to boot the minimal image in QEMU. qemu_boot.log

I have attached the results of boots for the "golden" image shipped with the ZU3 board, one I programmed on a Kingston SD card, and one I programmed on a Samsung SD card. I stopped the autoboot to get to the U-Boot prompt, where I did mmc info and mmc part commands. It looks like I have similar partitions set up compared to the golden image. Note that both the Kingston image is flaky, (sometimes boots, mostly not), and I only on some boots does the mmc part command show the proper partition. Comparing the golden to others, the primary differences I see are that the Kingston shows up in 1-bit wide mode, where the others a 4-bit. The kingston also has a sdhci_set_clock timeout message. There is also a disagreement between the Xilinx UG1144 and Digilent ZU3 Getting Started in terms of how many partitions and what type, and what files go into the partitions. sd_golden.txt sd_kingston.txt sd_samsung.txt

Booting my Genesys-ZU board with the SD card that shipped with it always results in a good boot. I tried rebuilding the OOB project in Vivado and PetaLinux. I program my SD card, and I get a good boot with it. If I cycle power on the Genesys-ZU, I get a failed boot, unless I leave the power switch off for a long period of time (several minutes). Then I get a good boot again. What could be wrong with the SD card image I created that would result in behavior like this? Attached is the console output captured. golden.txt is the boot with the shipped SD card, cap1.txt shows a bad boot with the card I programmed, cap2.txt shows a good boot after the board sat idle for several minutes. golden.txt cap1.txt cap2.txt

I tried this in PetaLinux 2020.2 with slightly better results, although not entirely successful. When I did the JTAG boot, I got a warning that a large image could cause problems, so it may be expected that it failed to boot. So I tried the JTAG / TFTP boot method instead. However, even building off of the the 3eg/oob/master repository, this also failed to boot. boot_jtag.txt boot_jtag_console.txt boot_tftp.txt boot_tftp_console.txt

I am also having similar problems with the ZU3 Digilent Genesys-ZU board not booting through JTAG when following the directions given. Do you get any output on the console during the boot?

The Digilent Getting Started guide does not actually show a petalinux-boot example, but has you program the SD card. Is petalinux-boot through JTAG broken in 2020.1? Perhaps I should try a different release? I'm hesitant, since the instructions specifically say you need 2020.1 for this out-of-the-box example. :(

Oh, I tried doing petalinux-boot --jtag --fpga before the steps above with similar results, except that the FPGA PL is showing programmed via the DONE LED. Also tried petalinux-boot --jtag --prebuilt 3 Also tried to run petalinux-package with the ../hw/proj/hw.runs/impl_1/system_wrapper.bit instead of images/linux/system.bit At one point, I ran petalinux-boot --jtag --fpga, and got much farther into the boot, but I have not been able to reproduce this. I don't even know what to read next.

No, I've seen that document, and I'm still stuck. I'm running Petalinux and Xilinx tools 2020.1. Attached are the results of the petalinux-boot command with --verbose turned on (command.txt), and also the serial port shows activity (serial.txt). Also I attached a listing of the pre-built/images/linux directory (prebuilt.txt), showing the system.bit *is* there. I built the PetaLinux project from the Digilent GitHub repository from the 3eg/oob/release/v2.1 tag. It looks like there are some missing steps in the guide. It looks like petalinux-boot is downloading over JTAG (except for the .bit file), and doesn't appear to run the kernel. If I connect manually with XSDB, I can see the targets--see targets.txt. I know I'm just missing something basic here. The documents are very hard to navigate when you're a newbie. But I am completely stuck right now. command.txt serial.txt prebuilt.txt targets.txt

I followed the directions at https://digilent.com/reference/programmable-logic/genesys-zu/[[getting-started]] to build and compile the Vivado project for the Genesys-ZU3 development board. I then configured and built the PetaLinux project using the directions on that page also. I then attempted to package and boot through JTAG with the following: $ petalinux-package --boot --fsbl images/linux/zynqmp_fsbl.elf --u-boot --fpga images/linux/system.bit --force INFO: sourcing build tools INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/zynqmp_fsbl.elf" INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/pmufw.elf" INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/system.bit" INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/bl31.elf" INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/system.dtb" INFO: File in BOOT BIN: "/home/ddickerhoof/Genesys-ZU/os/images/linux/u-boot.elf" INFO: Generating zynqmp binary package BOOT.BIN... ****** Xilinx Bootgen v2020.1 **** Build date : May 26 2020-14:07:15 ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved. [INFO] : Bootimage generated successfully INFO: Binary is ready. WARNING: Unable to access the TFTPBOOT folder /tftpboot!!! WARNING: Skip file copy to TFTPBOOT folder!!! $ petalinux-package --prebuilt --force INFO: Cleaning pre-built folder INFO: Updating software prebuilt INFO: Installing software images INFO: Pre-built directory is updated. $ petalinux-boot --jtag --prebuilt 1 INFO: sourcing build tools WARNING: Will not program bitstream on the target. If you want to program bitstream, WARNING: please run petalinux-package --prebuilt to put the bitstream to the prebuitl directory, WARNING: or use --fpga --bitstream option to specify a bitstream. INFO: Launching XSDB for file download and boot. INFO: This may take a few minutes, depending on the size of your image. rlwrap: warning: your $TERM is 'xterm-256color' but rlwrap couldn't find it in the terminfo database. Expect some problems.: Inappropriate ioctl for device INFO: Downloading ELF file: /home/ddickerhoof/Genesys-ZU/os/pre-built/linux/images/pmufw.elf to the target. INFO: Downloading ELF file: /home/ddickerhoof/Genesys-ZU/os/pre-built/linux/images/zynqmp_fsbl.elf to the target. INFO: Downloading ELF file: /home/ddickerhoof/Genesys-ZU/os/pre-built/linux/images/bl31.elf to the target. I see that system.bit is packaged, then put in prebuilt. But petalinux-boot says it will not program the FPGA bitstream. So I don't understand what the proper packaging and sequencing is required to configure the FPGA and boot the Linux system.

I am exploring the Git repository for the various branches and tags associated with the Genesys ZU-3EG Rev D board at https://github.com/Digilent. When I clone from the repositories, I get a constraint file for the Rev B board. What is the proper way to get the "out-of-the-box" (OOB) project with Git to rebuild for a Rev D board? How do I create the Vivado project for the Rev D board OOB project? I'm assuming there is some way to pull in the hw Git submodule for both OOB project and Rev D boards. If not, I cannot find where the board revision is specified before I source the hw/digilent-vivado-scripts/digilent_vivado_checkout.tcl script. I think the https://digilent.com/reference/programmable-logic/genesys-zu/[[getting-started]], rebuilding the Out-of-Box section must be missing some steps.