01-07-2019 08:20 AM
I have 3 ZCU-102 boards all acting the same. They are all the same shipment and all Rev1.1. They all pass BIST as instructed in the Quick Start Guide.
I have a known good SD Card with BOOT.bin, Image, and image.ub from prebuilt 2018 Q2. This card boots the ZCU-102s (Rev 1.1) from a previous shipment.
I set SW6 switches to "boot from SD" 4:1 1,1,1,0 (also called 0xE). This is the same setting as the ZCU-102 that does boot.
I see the message
The INIT_B and PS_ERR_OUT LEDs both are red at this point and there is no other output.
I do not believe there is anything wrong with these cards. The only configurations I have found relate to SW6 settings those settings with a previous ZCU-102 (Rev 1.1) does work.
Any help is appreciated.
01-07-2019 02:03 PM
So... you have one SD card that boots completely in 'old' ZCU102's "from a previous shipment", but that same exact SD card does not completely boot 3, separate 'new' ZCU102's. Is that the situation?
Are you certain the FSBL splash message is coming from the SD card image--and not from another bootable source, such as QSPI? A way to check that would be to re-build the SD FSBL in verbose/debug mode. A lot more text will be printed out, distinguishing it from an ordinary FSBL that could be running from another source.
Please clarify what you mean by "I set SW6 switches to... [4:1] 1,1,1,0"? In your narration, does a "1" put a switch in the "1" (closed) position--setting a Mode bit to 0, or the "0" (open) position--setting a Mode bit to 1?
I've been working on several Zynq MPSoC designs these last couple of years. SW guys love SD cards because they can program them quickly on a PC, then pop them into a board, to test a new build. Unfortunately, SD receptacles aren't rated for so many insertions and removals. We've ended up with bent pins on occasion, and have had to replace receptacles. It's unlikely you've got 3 bad SD receptacles, though.
Also, a frequent problem we've encountered is corruption of the SD card. We write a new BOOT.BIN or Image file (or whatever) onto the card, and then try to boot the board. The board doesn't boot--and the INIT and ERR LEDs are lit. (I don't recall getting any FSBL splash, though.) The fix has been to put the SD card back into the PC, write the files again, and then be sure to properly 'eject' the SD card before removing it from the PC. That usually fixes that problem. The fact that your SD card properly boots in older boards, however, dims the hope that you have a similar issue.
01-07-2019 10:47 PM
Turns out that on ES2 silicon with the REV 1 board the boot mode needs to be set to "E". After that change and a rebuild of the BSP from scratch my board boots but still has a ps_error led lit.
01-08-2019 05:38 AM
Answering in the order asked -
Yes, I believe you do understand my problem.
I am not positive but here is what I have followed-
Configure SW6 to QSPI32 and the board goes through BIST. I thought this was the only way to boot out of QSPI32.
On the working board I set SW6 to this picture (SD) and it boots.
I have even downloaded the BOOT.BIN and image.ub from the website
I put that onto my SD card and the "working" 102 boots no problem and the 3 new boards do not. I have tried formatting the FAT32 partition under both windows and Linux. I have also tried multiple SD cards including a sandisk 16GB Ultra class 10 that is on the "tested" list of approved media. https://www.xilinx.com/support/answers/66779.html.
I agree the chances of 3 failed boards are minimal. I am only in the 10s of mate/de-mate cycles. I follow ESD and try to be very gentle with these boards.
FYI I am a beginner with the Xilinx products. All I did was take the boards out of the boxes, set SW6 for BIST, and then set SW6 to boot from SD card. I have done nothing else. I was hoping that I had missed a step somewhere.
01-08-2019 05:49 AM
If you've encountered a board with a device having a different revision than you originally expected, you should go all the way back and upgrade the underlying HW design, too--then re-export the HDF. Just updating the BSP is not sufficient.
01-08-2019 06:06 AM
Dang. Seems like you're doing everything right--just no joy.
We're using a ZCU102 now, for the development of SW framework prior to the arrival of a new MPSoC-based prototype, but it's an older board.
Have you compared the older, working board and the newer, non-working boards, side-by-side? There may be (seemingly) unrelated jumpers or switches configured differently between them. That's another longshot, though.
Since the FSBL splash text from the BOOT.BIN appears on the terminal screen, the SD card appears to be getting read. The problem, then, would more likely be a hiccup occurring further into the boot cycle. Can you re-build the FSBL in verbose/debug mode--and then try to boot with a BOOT.BIN containing that version?
01-08-2019 06:27 AM
01-08-2019 06:39 AM
I have them side-by-side on an ESD bench. I see no difference in DIP switches or jumpers.
To answer your earlier question I have no hardware design. I am just trying to get Petalinux to build. Here are my commands -
petalinux-create -t project --template zynqMP --name test2 -s /home/ubuntu16/Downloads/xilinx-zcu102-v2018.2-final.bsp
petalinux-package --boot --fsbl ./images/linux/zynqmp_fsbl.elf --fpga ./images/linux/system.bit --pmufw ./images/linux/pmufw.elf --u-boot
I did try to add debug fsbl_debug.h but there was no additional output
In regards to your last post, I am not sure what you mean. What do you mean by "MPSoc devices". The boards are all labeled HW-Z1-ZCU102 and below that Revision 1.1. At this time we do not have any additional boards attached
01-08-2019 08:28 AM
If the 'newer' (non-booting) boards and the 'older' (booting) boards have the same version, they should contain the same revision Zynq MPSoC (or Zynq MP, or Zynq+--as opposed to the plain, old simple "Zynq") chip. In the 'old' days, all you would have to do is look at the information stamped on the case. Nowadays, you need to query the innards of the part.
Using Vivado, verify that the booting and non-booting boards have the same chips on them. In HW manager, verify that they have the same ID Codes:
Your ID codes will be different than the one above, but they should be the same as each other. If they're not, that could be why an image that boots on one board doesn't boot on the other.
01-09-2019 08:49 AM
The FSBL is starting, which means the SD card is detected, and the boot process begins. The exact same SD card is tried in both type of boards. The boot succeeds on an 'older' Rev 1.1 board, but stalls on 3 different 'newer' Rev 1.1 boards--and all have the same revision Zynq MPSoC.
That certainly seems to indicate a difference/problem with the newer boards.
I assume the second stage boot loader is U-boot...? But there's no screen-output from that software, which means any problem probably involves 1) the PMU firmware--but it works on the older board, 2) any enclosed bit file--but that works on the older board, or 3) the BL31 (trust zone) firmware--but that works on the older board, too.
I would encourage you to try to build a bootable image, with an FSBL in verbose/debug mode. That FSBL will provide more information during the boot, hopefully providing information as to the underlying problem.
SD card boot starts-off with a slow clock, which speeds up at some point. It's been a while since I've debugged a boot cycle, so I can't remember which stage that happens in. There might still be a hardware problem with the SD card interface, that allows low-speed accesses to work, but failure occurs when the clock speed is increased. You'd need to run an SD card diagnostic to check that.
01-10-2019 05:40 PM
Have you seen this Answer Record?
I also think there might be some useful information in this thread:
01-11-2019 12:01 PM
Thank you for the advice. I took 1 of my cards and re-installed the QSPI flash. It no longer runs BIST and now fails in the same manner as booting from SD card. I see the FSBL note, it than hangs there.
01-13-2019 11:24 AM
Dear Xilinx Support:
I have the same issue when I received the ZCU102 board two weeks ago and have the same problem when I followed the instruction (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842112/Zynq+UltraScale+MPSoC+Ubuntu+part+1+-+Running+the+Pre-Built+Ubuntu+Image+and+Power+Advantage+Tool). I set the switch 6 to 1,000, 0,0,0,1, it still does not work.
It appears that all shipments recently have the same problem. Should I return the board and get a different ZCU104 or 106?
Does Xilinx provide any working solution for booting from SD for the new shipment?
A frustrating user.
01-15-2019 01:26 PM
This seemed interesting:
Is the PS for your ZCU102 plugged into the same outlet/strip as your monitor PC?
01-17-2019 10:36 AM - edited 01-17-2019 10:38 AM
Could you please enable the debug prints in the fsbl and then rebuild? This will give more details as to why this is failing.
To do this, in your petalinux project
1. Create a fsbl and files directory in meta-user layer if it is not already present
2. Create a fsbl_%.bbappend file and add below content.
XSCTH_BUILD_DEBUG = "1" YAML_COMPILER_FLAGS_append = " -DFSBL_DEBUG_DETAILED"
3. Rebuild and copy the images to the SD card. Please share your log after you do.
01-22-2019 01:28 PM
01-22-2019 02:26 PM
Can you post your SD images (2018.3) so that I can download and install?
I use the instruction (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842112/Zynq+UltraScale+MPSoC+Ubuntu+part+1+-+Running+the+Pre-Built+Ubuntu+Image+and+Power+Advantage+Tool). The zip file only contain the 2017 version.
01-22-2019 02:33 PM
01-23-2019 03:48 AM
Sorry for the delay in responding, my work schedule got in the way.
After working a service ticket and working with AVnet, this is what I have figured out.
There are some rev1.1s that do NOT work with 2018.2 distribution. To prove it I simply went here -
I was able to download 2018.2 and 2018.3. The .2 images would not boot on my 4 new boards. The .2 would boot on my older board. The 2018.3 images booted everything.
I then downloaded the full 2018.3, built my petalinux environment and am back up and runnign with all my boards.
01-24-2019 02:09 PM
Yes, most recent ZCU102 have a new SODIMM that requires 2018.3 FSBL in order to properly work.
2018.3 FSBL is also back compatible for older boards.
I think there's an Answer Record out there explaining this.
01-28-2019 09:07 AM
Could you provide link to Answer Record - I haven't been able to locate it.
We are also having problems later that seem to indicate a SODMM chage can't be the only issue requiring 2018.3.
Is there a concise list of changes between 2018.2 and 2018.3 ?
02-19-2019 10:14 AM
Could you pin this or somehow bump it?
This is very important to know. I have just received a zcu102 that is behaving exactly the same way. If I had not bothered to read through this entire thread then I would not have known about the dependancy of Petalinux 2018.3 on the newer boards.
02-21-2019 10:44 AM