News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

Petalinux QSPI Boot issue on Custom board with TE0807

Started by msattine, February 04, 2020, 02:28:30 PM

Previous topic - Next topic

msattine

Hi,
  I am facing an issue with QSPI boot on Custom board which has TE0807. I tried a bare metal application throuh QSPI boot and it worked with no issues.

Below is the procedure that I followed to boot petalinux image through QSPI.

-petalinux-config
  Modified the boot size to 0x1E00000, this resulted in the kernel image offset to 0x1E40000

-petalinux-build

Then used xilinx SDK to build BOOT.bin image. Below is the bif file
//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
   [fsbl_config]a53_x64
   [bootloader]./zynqmp_fsbl.elf
   [destination_cpu = pmu]./pmufw.elf
   [destination_cpu = a53-0, exception_level = el-3]./bl31.elf
   [destination_cpu = a53-0, exception_level = el-2]./u-boot.elf
   [offset = 0x1E40000, destination_cpu = a53-0]./image.ub
   [destination_device = pl]./system.bit
}

Then connected through JTAG and flashed the image from SDK with the boot pins in JTAG boot mode.

Then changed the boot mode to QSPI and turned on the board.

What I observe on the serail console is just the below messages:

Xilinx Zynq MP First Stage Boot Loader
Release 2019.1   Feb  3 2020  -  03:39:58
PMU Firmware 2019.1     Feb  3 2020   03:34:02
PMU_ROM Version: xpbr-v8.1.0-0

I also see that PS_DONE LED is ON which means PL configuration is done.

Why are the u-boot messages not coming on console and no login prompt?

Am I doing something wrong? Any debug suggestions are much appreciated.

-
Mohan

JH

Hi,
do you have one of our carrier for test?

Can you check power supply of  your carrier? Maybe module restarts, on power up it need more current.
You can enable debug messages of the FSBL to see more details:
https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
--> use detail debug messages

br
John

msattine

Hi John,
   Another update

I tried booting without bitstream in the bif file and it worked upto u-boot.

So, looks like an issue with PL configuration itself. So, I tried to just load bitstream through JTAG and received "fpga configuration failed. DONE PIN is not HIGH"

I tried reading PCAP_STATUS register (0xFFCA3010) and it gave 0xA0000A46
When I checked for the definition of the bits
  - PL has comleted its init sequence
  - PL configuration is not done
  - PL has not reached end of startup
  - PL has not completed its first configuration

Any idea where the problem is?

-
Mohan



JH

did you select the correct FPGA/SoC  in your design?

And PL has separate power rails, check these also.
br
John

msattine

Hi John,
Yes, I did selected the right FPGA in Vivado.

To add further, I tried programming the same FPGA bitstream file on TEBF0808 and it worked with no issues (the PL configuration)

Another update is that when I flash FPGA with this bitstream file and power up the board in QSPI mode, it works fine. It strange but it is how it is.

Regards,
Mohan


msattine

Hi John,

Below is UART message dump with fsbl debug enabled:
---------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader
Release 2019.1   Feb  6 2020  -  14:39:22
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU7EV
Processor Initialization Done
================= In Stage 2 ============
QSPI 32 bit Boot Mode
QSPI is in Dual Parallel connection
QSPI is using 4 bit bus
FlashID=0x20 0xBB 0x20
MICRON 512M Bits
Multiboot Reg : 0x0
QSPI Reading Src 0x0, Dest FFFF1C40, Length EC0
.QSPI Read Src 0x0, Dest FFFF1C40, Length EC0
Image Header Table Offset 0x8C0
QSPI Reading Src 0x8C0, Dest FFFDB088, Length 40
.QSPI Read Src 0x460, Dest FFFDB088, Length 40
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x8
Partition Header Address: 0x440
Partition Present Device: 0x0
QSPI Reading Src 0x1100, Dest FFFDB0C8, Length 40
.QSPI Read Src 0x880, Dest FFFDB0C8, Length 40
QSPI Reading Src 0x1140, Dest FFFDB108, Length 40
.QSPI Read Src 0x8A0, Dest FFFDB108, Length 40
QSPI Reading Src 0x1180, Dest FFFDB148, Length 40
.QSPI Read Src 0x8C0, Dest FFFDB148, Length 40
QSPI Reading Src 0x11C0, Dest FFFDB188, Length 40
.QSPI Read Src 0x8E0, Dest FFFDB188, Length 40
QSPI Reading Src 0x1200, Dest FFFDB1C8, Length 40
.QSPI Read Src 0x900, Dest FFFDB1C8, Length 40
QSPI Reading Src 0x1240, Dest FFFDB208, Length 40
.QSPI Read Src 0x920, Dest FFFDB208, Length 40
QSPI Reading Src 0x1280, Dest FFFDB248, Length 40
.QSPI Read Src 0x940, Dest FFFDB248, Length 40
QSPI Reading Src 0x12C0, Dest FFFDB288, Length 40
.QSPI Read Src 0x960, Dest FFFDB288, Length 40
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x5CBE
Data word offset: 0x5CBE
Total Data word length: 0x5CBE
Destination Load Address: 0xFFDC0000
Execution Address: 0xFFDD0108
Data word offset: 0x7AF0
Partition Attributes: 0x83E
QSPI Reading Src 0x1EBC0, Dest FFDC0000, Length 172F8
.QSPI Read Src 0xF5E0, Dest FFDC0000, Length 172F8
Partition 1 Load Success
======= In Stage 3, Partition No:2 =======
UnEncrypted data Length: 0x249
Data word offset: 0x249
Total Data word length: 0x249
Destination Load Address: 0xFFDDB32C
Execution Address: 0x0
Data word offset: 0xD7B0
Partition Attributes: 0x83E
QSPI Reading Src 0x35EC0, Dest FFDDB32C, Length 924
.QSPI Read Src 0x1AF60, Dest FFDDB32C, Length 924
Partition 2 Load Success
======= In Stage 3, Partition No:3 =======
UnEncrypted data Length: 0x100
Data word offset: 0x100
Total Data word length: 0x100
Destination Load Address: 0xFFDDF6E0
Execution Address: 0x0
Data word offset: 0xDA00
Partition Attributes: 0x83E
QSPI Reading Src 0x36800, Dest FFDDF6E0, Length 400
.QSPI Read Src 0x1B400, Dest FFDDF6E0, Length 400
PMU Firmware 2019.1     Feb  3 2020   03:34:02
PMU_ROM Version: xpbr-v8.1.0-0
Partition 3 Load Success
======= In Stage 3, Partition No:4 =======
UnEncrypted data Length: 0x299953
Data word offset: 0x299953
Total Data word length: 0x299953
Destination Load Address: 0xFFFFFFFF
Execution Address: 0x0
Data word offset: 0xDB00
Partition Attributes: 0x26
QSPI Reading Src 0x36C00, Dest 100000, Length A6654C
.QSPI Read Src 0x1B600, Dest 100000, Length A6654C
Destination Device is PL, changing LoadAddress
Non authenticated Bitstream download to start now
DMA transfer done
XFSBL_ERROR_BITSTREAM_LOAD_FAIL
Partition 4 Load Failed, 0x37
================= In Stage Err ============
----------------------------------------------------------------------------

I checked PL_DCIN during power up and it looked fine. Do you want me to check it with reference to any other supplies?

Regards,
Mohan.

JH

hi,
which mio did you use for uart? Same like we use with tebf0808?
if yes, can you try out prebuilt boot.bin from 2019.2 test_board reference design:
https://wiki.trenz-electronic.de/display/PD/TE0807+Test+Board
You must program flash with these boot.bin and boot from flash because SD is disabled on the test board design.

br
John

msattine

Hi John,

I used MIO 18 and 19 for UART (different from TEBF0808).

PROG_B and INIT_B pins are not connected on the custom board as they are pulled high on TE0807. I hope this is ok?

One observation on looking at PL_1V8 and PROG_B signals. I see that PROG_B is going high before PL_1V8. Is this OK? I am asking this because documentation says that PROG_B is for PL configuration reset. But if PL_1V8 is PLs internal voltage and PROG_B is ahead of PL_1V8 how are we sure that PL configuration is getting reset? Can this cause any problem?

JH

hi,
yes. There is a Main Reset (MR), which must be hold low until all power you need are good. PL will not checked by module itself because it's optional:
https://wiki.trenz-electronic.de/display/PD/TE0807+TRM#TE0807TRM-VoltageMonitorCircuit
br
John

msattine

Hi John,
         Im confused. Do you mean this is ok or is it a problem?
Sorry! for the confusion

Regards,
Mohan.

JH

Hi,
QuoteCan this cause any problem?
--> yes

So I think this is the problem. Your PL is not powered up but PS  (running FSBL) try to configure PL.

br
John

msattine

Hi John,
  On this board we connected MR pin to 1.8V supply which is also driving VCCO.

But the confluence page says that the voltage should be VDD (3.3V).
Is there any way to confirm that this is what is causing the issue.

Sorry! for so many questions. This is the first time I am working on FPGA.

Regards,
Mohan.

JH

Hi,
you has see:
https://wiki.trenz-electronic.de/display/PD/TE0807+TRM#TE0807TRM-VoltageMonitorCircuit
In case 1.8V is not enough POR_B should be hold zero and FPGA should completely not boot.
We use: TPS3106K33DBVR
has internal pullup to LP_DCDC, with 1.8V  is more lucky, if I see it correctly in the datasheet.
Can you hold MR down until PL PG is high?

but you wrote
QuoteOn this board we connected MR pin to 1.8V supply which is also driving VCCO.
so you directly power variable bank power without checking if core power ready? Or did you check PGOOD?
See https://www.xilinx.com/support/documentation/data_sheets/ds925-zynq-ultrascale-plus.pdf
page 15ff

br
John

msattine

Hi John,

We do check power good on all power rails.

We tried holding POR_B low during power up (have a jumper to do it). But this didnt help.

Regards,
Mohan

JH

Hi,
can you share your schematics? I can check one time, if I find out something. You can send it to support@trenz-electronic.de

br
John

msattine

Hi John,

Another update from further debug.

The issue seems to be with QSPI flash. I was flashing without enabling verify option and so never worried if the flash operation was successful. Now I tried flashing with verify option enabled. The QSPI boot failed whenever flash verification failed.

This is not consistent but is happening frequently.

Any ideas as to what could be the issue?

-
Mohan

JH

Hi,
this should normally not happens.
Which power up sequencing did you use?
We will check the schematics which you has send use, but this takes some time.

Do you have one of our carrier to test JTAG programming?
Maybe its some communication problem.
Can you try to program with slower speed and if possible also use our carrier?


br
John