cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
toombzie
Visitor
Visitor
893 Views
Registered: ‎01-08-2020

Am I creating the FSBL correctly? (Embedded Linux)

Jump to solution

Hello,

I am working with a CHREC board -- it has a Zynq 7020 on it, and I'm having trouble getting it to boot properly.  The manufacturer provides some sample programs of which all work perfectly, but their sample programs do not have the processor configured the way I would like it to be configured.  In particular, for the linux application example, they provide an fsbl.elf file that simply works while I am trying to generate a new one as I have a different ps7_init.c configuration.

Therefore I created my own Vivado project, made the block design, configured the PS, validated the design and took it all the way to creating a bitstream which it did without errors.  I'm using Vivado IDE 2017.1.  

Now in Vivado SDK, I imported the hardware, and then I'm going to New Application Project and choose the custom hardware platform I made and OS Platform of Standalone

FSBL_New_App_Project.png

Then I hit next and choose Zynq FSBL and click finish

FSBL_New_Project.png

Because the program automatically builds, this creates the FSBL.elf file in the Debug folder of the workspace directory.

I then am using bootgen to create the image -> so I use this FSBL, my custom bitstream, then the u-boot and xilinx-linux package the manufacturer of the board provides. This code I basically copied from the working instance that the manufacturer provides -- only I substituted my fsbl.elf file and my bitstream.bit file.

However, using this FSBL the board does not boot and the FPGA does not program.  I can't even use the Xilinx SDK debugger to step through the FSBL code -- it doesn't seem to really do anything.  Nothing populates in the Variable table.  I can get the SDK to program the FPGA chip directly, and it completes without reporting any errors.

Is there something special to check in the FSBL to make this work?  It's supposed to be loading from NAND.

0 Kudos
1 Solution

Accepted Solutions
toombzie
Visitor
Visitor
731 Views
Registered: ‎01-08-2020

For this issue -- I finally figured out the problem.  The Xilinx SDK linker generator -- at least for my project -- wasn't mapping the memory regions correctly.  Going to Xilinx Tools -> Generate Linkers script created that linker script with every memory region mapped to DDR (as in my screenshot in a previous post).

But what I needed to do was change that to ps7_ram_0 for everything except the .stack, which needs to be ps7_ram_1.

updated_memory_locations.png

I confess I don't know why this worked -- probably something in the background and specific to my particular project, but I guess if anyone has a similar issue they could try the same thing and see if it works...

What clued me into this issue was using the linux command readelf -e <fsbl.elf> command on a working fsbl.elf file and the custom one I was creating using the Xilinx SDK.  Check the addresses for each section, as well as the offset and maybe change the memory segments around to get it to match.

read_elf.png

View solution in original post

4 Replies
shirilt
Xilinx Employee
Xilinx Employee
836 Views
Registered: ‎05-15-2018

Hi @toombzie 

You can download the petalinux 2017.1 BSP for the zynq7000 based board that most closely matches your custom board. Then you can use the pre-built fsbl binary (located in <path-to-extracted-BSP>/pre-built/linux/images/zynq_fsbl.elf), and see if that is able to boot up your board. If this works, then the issue probably lies with your design. If it does not, then it can be deduced that the manufacturer-provided fsbl.elf has something specific which is able to boot up your board, which the stock FSBL is unable to do.

To debug the FSBL source code:

In order for making the FSBL fit in the OCM, Linker time optimizations have been turned on for FSBL and fsbl_bsp. In order to do src level debug, you need to turn optimizations off.

For fsbl:

  • right click on fsbl, select C/C++ Build settings
  • Select ARM A53 gcc compiler->Miscellaneous
  • remove "-Os -flto -ffat-lto-objects" from 'other flags'

For fsbl_bsp

  • right click on fsbl_bsp and select Board Support Package Settings
  • Select overview->standalone
  • change zynqmp_fsbl_bsp value from 'true' to 'false'

If you find your fsbl doesn't fit any more, you can disable features by enabling the EXCLUDE defines in xfsbl_config.h.

This is also documented at https://www.xilinx.com/support/answers/71671.html

Other than that, the procedure you have described for building the FSBL seems correct to me.

---------------------------------------------------------------------------
Don’t forget to Reply, Kudo, and Accept as Solution.
---------------------------------------------------------------------------
0 Kudos
toombzie
Visitor
Visitor
809 Views
Registered: ‎01-08-2020

Hello @shirilt 

Thanks for the reply. I did as you suggested with Petalinux and I got some of the same results I've been having in the sense that some FSBL's that I've tried out (for baremetal applications or for similar boards) actually do load the FPGA but then the kernel fails to load due to some conflict.  This I believe is a problem with the kernel configuration, which at the moment I'm not that concerned about.  

The issue I'm trying to solve is when my bootgen image (which consists of a FSBL I am creating, a bitstream for the fpga, and then a u-boot and linux image) does not actually load the fpga and it gets stuck.

I may have stumbled onto the source of error.  When I was testing out a baremetal app, I loaded a FSBL that has a default setting for the lscript.ld that looks like:

lscript_default.png

These locations are auto-generated by Xilinx SDK.  I used the FSBL.elf that these settings created, loaded it, and then the board booted but the kernel didn't load due to those configuration errors that I suspect I'll be troubleshooting shortly.

Then I went back to the SDK, wen to Xilinx Tools -> Generate Linker which then shows this screen:


generate_lscript.png

The advanced tab on this screen seems odd - says compiled size of every section is 0?  Is this normal? 

advanced_lscript.png

I then click Generate and it makes a new lscript.ld as shown:

lscript_generated.png

However, now when I use the fsbl.elf that this creates (with this new generated linker script), I get the error where the fpga does not program.  So it seems like there is something wrong with this linker script -- however I'm not sure how to figure out what it should actually look like or what is wrong about it.

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
797 Views
Registered: ‎09-12-2007

You are creating the FSBL fine. The issue is most likely how you configured the PS in Vivado. Can you ask the vendor of the board to send you the pcw settings for the ps in Vivado that you can use as a reference to make your changes?

0 Kudos
toombzie
Visitor
Visitor
732 Views
Registered: ‎01-08-2020

For this issue -- I finally figured out the problem.  The Xilinx SDK linker generator -- at least for my project -- wasn't mapping the memory regions correctly.  Going to Xilinx Tools -> Generate Linkers script created that linker script with every memory region mapped to DDR (as in my screenshot in a previous post).

But what I needed to do was change that to ps7_ram_0 for everything except the .stack, which needs to be ps7_ram_1.

updated_memory_locations.png

I confess I don't know why this worked -- probably something in the background and specific to my particular project, but I guess if anyone has a similar issue they could try the same thing and see if it works...

What clued me into this issue was using the linux command readelf -e <fsbl.elf> command on a working fsbl.elf file and the custom one I was creating using the Xilinx SDK.  Check the addresses for each section, as well as the offset and maybe change the memory segments around to get it to match.

read_elf.png

View solution in original post