04-10-2019 03:50 AM - edited 04-10-2019 04:05 AM
Hi
I have read the MPSoC TRM with its description of the boot mode pins for the PS booting.
However my colleagues have stated that on previous generations of Xilinx FPGAs you do not need to have these pins wired to boot from JTAG, and the conneciton of JTAG overides the boot sequence/
Is this correct?, The table below from the US+ TRM seems to sugggest to boot from JTAG you need to set the boot mode to 0000.
References to documentation to support this would be appreciated.
Thanks
Tim
04-10-2019 09:28 AM
The TRM, UG1085 for the Zynq UltraScale + MPSoC, describes the boot mode pin settings necessary for the desired boot mode. For JTAG, that is 0000 as shown in tbale 11-1 that you posted.
04-11-2019 12:50 AM
thanks @glena , That is my understanding, however i have been told previous generations allowed booting and programming from Impact/Vivado without setting/changing the boot mode pins to JTAG.
I would like to know is this is still true for the Ultrascale MPSoC?
04-11-2019 02:39 AM
What is your bootmode set to? If you have this set to QSPI mode (for example), and you have no valid image here. Then you will most likely see the dummy_dap in the jtag chain after power up. If you do have a valid image here, it will attempt to boot, but you can connect to jtag.
See Figure 39-1:
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
04-11-2019 03:35 AM - edited 04-11-2019 03:51 AM
thanks, @stephenm , we would have the boot mode pins set to QSPI but we would need to program the board for bringup.
I took a look at the document but it wasn't clear, I'm assuming the CSU ROM would look for an image at the location set by the boot mode pins if this fails i'm not sure what it would do?, you seem to suggest as my colleague has that it will fall back to jtag?
Or does the JTAG hold the CSU in reset and change the boot mode registers ?
(use_alt = 0001 , alt_boot_mode = 0000)
04-11-2019 03:56 AM
If it fails to find the image it should default to the dummy_dap. For example:
04-11-2019 04:22 AM
thanks again @stephenm , for some reason my kudo button arnt working, to show my appreciation.
What is the benefit of fitting switches/jumpers to boards for the boot mode pins as the Evaluation boards do, seems JTAG value is surplus to requirements.
Thanks
Tim
04-11-2019 05:50 AM
The benifit of bootmode selection is change the boot flash device. If you only are booting QSPI, then QSPI is all you would need in most cases. I would advise selecting QSPI32.
I said most cases because there may be QSPI images that can put your hardware in a state where it will not reprogram the QSPI device with the standard FSBL as a guide. In that event, you can either short the bootmode pins to ground briefly while sending a PS_POR_B or edit the code in xfsbl_initialization.c to make the FSBL think it's booting in JTAG mode.
04-11-2019 06:23 AM - edited 04-11-2019 06:50 AM
Thanks again
So the design will use QSPI and we will boot strap it for that in the PCB, with not option to change the bootmode pins.
So we need to activly set the boot mode to JTAG during development in the FSBL(xfsbl_initialization.c) , to enable us to recover later if we manage to get into a state where the bootloader cannot program the QSPI? , or can this be done after we are "stuck"?
I'm confused you mention FSBL Guide and not boot.bin?, what is FSBL guide?
Seem the kudos issue i had was internet explorer issue, chrome on my mobile is ok.
04-11-2019 06:31 AM - edited 04-11-2019 06:31 AM
In most cases you can reprogram QSPI when booting in QSPI mode. There are some cases where that does not work. So, you can manually short the mode pin to ground and issue a PS_POR_B - boot mode is checked very early after release of PS_POR_B.
If you don't have access to those signals, then you can edit xfsbl_initialization.c in your guide FSBL (do not edit your FSBL in boot.bin)
04-11-2019 06:59 AM - edited 04-11-2019 06:59 AM
THnaks @glena,Could you elabourate on the "Some cases where that wouldn't work"?
Do we have to edit the xfsbl_initialization.c in FSBL before we get stuck?, would you advise doing this for development only , then reverting when in produciton?
You mention "guide" FSBL what do you mean by guide?
Thanks for the help , this is really helping understand the boot process.
04-11-2019 07:05 AM
Guide FSBL = the FSBL required by program_flash to program your device. This does not need to be the same FSBL that is in your boot.bin.
If you make this edit, ONLY edit the guide FSBL. Do not make these edits on the FSBL that is in your boot.bin
Program_flash programs whatever is in boot.bin, it does not open it, does not read it, has no knowledge of the contents. The guide FSBL is necessary to set up the clocks and MIOs on the ZU+ MPSoC and prepare it for the mini u-boot that programs the QSPI.
04-11-2019 07:47 AM
There are pull up resistors on the bootmode pins. This is used during bootrom to set the bootmode register, asnd load the fsbl. Fsbl then takes over to load other partitions in boot image.