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

SD card boot on TE0715+TE0703

Started by jwdonal, March 26, 2018, 04:54:03 AM

Previous topic - Next topic

jwdonal

Hello,

I have been having great success with the TE0715+TE0703 board combo. I have successfully programmed and booted a baremetal project from QSPI, and I have also programmed and booted Linux from the SD card using u-boot. I have done both of these from scratch without using any provided reference designs - only the TRMs. Everything is working well and all peripherals are functioning properly under linux and I have Ubuntu 16.04 LTS running on the board.

However, I do have one question that is bothering me. Whenever I have booted linux from an SD card on other Zynq development boards (e.g. the Picozed+FMC carrier card), the general flow is as follows:

1) Zynq Boot ROM loads FSBL (embedded in BOOT.bin image file) from SD into OCM
2) FSBL loads U-boot (also embedded in BOOT.bin image file) from SD into DDR
3) U-boot loads bitstream (stored on FAT partition, _not_ part of BOOT.bin image) from SD into FPGA
4) U-boot load Linux image (stored on FAT partition, _not_ part of BOOT.bin image) from SD into DDR
5) U-boot launches/runs Linux


This is the standard flow that I have always been familiar with. However, on the TE0715+TE0703 there appears to be some additional steps/actions taken _before_ Step 1 shown above. There seems to be a hidden Step 0 on the TE0715+TE0703 which expects and _requires_ a bitstream file to be included as part of the BOOT.bin image. This Step 0 actually loads and configures the FPGA with this bitstream. The reason I know this is happening is because the D2 LED (which is inverse of FPGA 'DONE' signal) on the TE0715 board turns off _before_ U-boot loads the bitstream in Step 3 above.  So what is happening in my case is the FPGA is actually being configured twice - once when power is first applied to the board and once when u-boot does in Step 3.

So the real flow on the TE0715+TE0703 for booting from the SD card is as follows:
0) Some unknown entity loads and configures FPGA with the bitstream that is embedded in BOOT.bin image file
1) Zynq Boot ROM loads FSBL (embedded in BOOT.bin image file) from SD into OCM
2) FSBL loads U-boot (also embedded in BOOT.bin image file) from SD into DDR
3) U-boot loads bitstream (stored on FAT partition, _not_ part of BOOT.bin image) from SD into FPGA
4) U-boot load Linux image (stored on FAT partition, _not_ part of BOOT.bin image) from SD into DDR
5) U-boot launches/runs Linux


What is annoying about this behavior is that I am required to embed a bitstream file into my BOOT.bin in order to be able to boot from the SD card. My BIF files on every other Zynq board that I've used are setup as follows:

//arch = zynq; split = false; format = BIN
the_ROM_image:
{
[bootloader]my_fslb.elf
u-boot.elf
}

And in the above case the bitstream is loaded by u-boot from the bitstream file stored on the FAT partition (there is _no_ bitstream embedded in the BOOT.bin file).

However, on the TE0715+TE0703 if I generate a BOOT.bin using the BIF setup shown above the board will _not_ boot from the SD card and hangs. Instead I have to use a BIF like the following:

//arch = zynq; split = false; format = BIN
the_ROM_image:
{
[bootloader]my_fslb.elf
        my_bitstream.bit
u-boot.elf
}


So my questions are:

1) Why do I have to include a bitstream as part of my BOOT.bin on the TE0715+TE0703?
2) ___What___ or ___who___ is loading the bitstream file into the FPGA in Step 0?  Is the CPLD doing something that I am unaware of?

Thank you.

JH

Hi,

this is default xilinx flow to use FSBL for bitstream loading. See FSBL source code or Xilinx documentation.

You can also use uboot or what ever else.  There are many way to work with Zynq. We provide only one way.

Br
John

jwdonal

Normally the FSBL does not require a bitstream to be embedded in the BOOT.bin. If a bitstream does exist then the FSBL will read it and will configure the FPGA. But if the bitstream does not exist then it will simply load the subsequent ELF file (in this case u-boot) into DDR and jumps to execute that code. You can see this in the FSBL source.

So there must be something else on the board (or possibly in the CPLD logic) which is requiring the bitstream in the BOOT.bin file? Requiring the bitstream to be part of the BOOT.bin file is not standard flow nor standard behavior given my experience on numerous other Zynq development boards. Having the bitstream embedded in the BOOT.bin is optional, but should not be required.

JH

Hi,

I that know, bitfile is optional on FSBL. But there is no restriction from our side. I've tried out, see attachment pictures.

Can you enable FSBL_DEBUG_INFO?

br
John



jwdonal

Sure. I have attached the FSBL debug info output from UART0 as requested. I have attached one log for when the BOOT.bin file includes the bitstream and one from when the BOOT.bin file does not include the bitstream.

In the case where the BOOT.bin includes the bitstream, the boot sequence completes and U-boot executes, loads bitstream, and runs linux.
In the case where the BOOT.bin does _not_ include the bitstream, the boot sequence hangs/stops after "FSBL Status = 0x1" is printed and U-boot never loads/runs.

Please note that u-boot ELF is configured for stdout on UART1 (instead of UART0) in case you think that's relevant information. Although this shouldn't make any difference.

JH

#5
Hi,

so it seems, your Uboot has a problem. FSBL finished on both logs. Do you use UAR1 over EMIO? Or did you add something else on PL side, where Uboot can try to get access? Attempted access to unconfigured PL part can be a problem.
Can you try one time simple hello World and/or UBoot with UART0 instead of UART1, if you use PL UART.
I will try out this with our uboot from the reference design tomorrow.

br
John

JH

Hi,
our uboot works also without bitfile, see attachment.
br
John

jwdonal

Thanks for the info. Which UART did your u-boot use?  UART0 or UART1?


jwdonal

I tested with a hello_world app that used UART0 and it executed fine after the FSBL handoff.

It seems strange that the UART peripheral (0 or 1) would make any difference. After all, u-boot shouldn't care what UART it's using and I don't think it knows whether the UART is using fixed MIO or EMIO in the fabric. This is definitely a mystery...

JH

Hi,
is your UART1 MIO or EMIO?
br
John

jwdonal

#11
My UART1 is EMIO with only RXD/TXD signals (no RTS/CTS modem signals). This means that I will not see any u-boot output until u-boot configures the FPGA, but this is fine because I don't need to interact with u-boot, I just need to see the linux boot sequence.

I did have an idea that maybe because the fabric wasn't configured that the UART1 RX input from the fabric was floating and causing the u-boot "Press any key to abort boot sequence..." to trigger, but I changed the u-boot bootdelay variable to 0 seconds (which causes it to skip the abort option) and it still hung. It was worth a shot at least...

Maybe the Zynq PS internally restricts/prevents access to the hard peripherals that are configured for EMIO until the FPGA is configured? Maybe it's some kind of safety mechanism? I've never heard of this before but it's possible... I could ask our Xilinx FAE he might know.

Hmmm...here's another idea. Configure the FSBL to have its stdin/stdout on UART1 EMIO and see if it still loads the bitstream. I'll try that now...

UPDATE: I just reconfigured the FSBL to use UART1 EMIO for its stdin/stdout and it ran just fine with no problems at all. So there is clearly no internal restriction in the Zynq to prevent access to EMIO peripherals prior to FPGA configuration.

JH

Hi,

maybe you can find some notes here:
but at the moment i think also there is some interaction with the unconfigured PL, which stops your Uboot.

PS: possible workaround: Add compressed bitfile with only UART1 connected to the Boot.bin (so Boot.bin is also smaller) and reconfigure PL again with your needed bitfile over uboot.

br
John

jwdonal

Quote from: JH on March 28, 2018, 10:45:44 PMPS: possible workaround: Add compressed bitfile with only UART1 connected to the Boot.bin (so Boot.bin is also smaller) and reconfigure PL again with your needed bitfile over uboot.
Yes, this is the same idea we had.

I just wish I could figure out what is stopping this thing from booting. I don't like not knowing why something doesn't work...

JH

Hi,
Quote
UPDATE: I just reconfigured the FSBL to use UART1 EMIO for its stdin/stdout and it ran just fine with no problems at all. So there is clearly no internal restriction in the Zynq to prevent access to EMIO peripherals prior to FPGA configuration.
Does your FSBL use Uart input? I think not, default FSBL use only output. So UART can be also the problem.

Did you connect something to AXI Bus? Which Uboot try to get access on? If request on AXI get no response, then the system gets stuck.

br
John

jwdonal

Quote from: JH on March 29, 2018, 09:13:45 AMHi,Does your FSBL use Uart input? I think not, default FSBL use only output. So UART can be also the problem.
That's a very good point and great observation. So I modified the FSBL code to make one call to the inbyte() function so that it would read one byte from the UART1 before it programmed the bitstream. It still did not hang. So there still seems to be no restrictions for using EMIO peripherals before the FPGA is programmed.

Quote from: JH on March 29, 2018, 09:13:45 AMDid you connect something to AXI Bus? Which Uboot try to get access on? If request on AXI get no response, then the system gets stuck.
There is nothing in the fabric except for the UART1 EMIO. The only other things in the design are the hard peripherals that are connected to the fixed MIO.

GF

Hello World!

Excuse me for replying onto an old post but at the moment we are facing a very similar problem as described here. We are using multiple TE0715-04 Trenz modules and mating them with in-house developed carrier boards. We have been using this setup for the last one year and mostly it has been working flawlessly.

But as described here, the modules refuse to boot up when there is no bitstream present in the boot image. The FSBL iterates without any errors but the UBOOT never gets the handle and thus never starts executing. It does not matter what is included in the FPGA bitstream, even if it is empty, the board always boots up and switch from FSBL -> UBOOT -> Linux Kernel is seamless. We have also booted up the board strictly through JTAG only (FSBL+UBOOT+KERNEL) but the problem remains the same.

Has anybody found the reason for this problem? It would be great to know why it is happening. We believe it is only limited to the TE0715 as we are also using TE0720 and that module does not show this behaviour.

Best regards