UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor egholm
Visitor
4,687 Views
Registered: ‎05-13-2016

[2016.3, Zynq MPSoC, FSBL] Fsbl handoff bug/understanding when "load" lines in boot.bif are shuffled?

Jump to solution

Hi,

 

I've been struggling the last couple of hours with getting my R5 FSBL (manually build from embeddedsw GIT) to do proper handoff to a bare-metal R5 application.

 

With the boot.bif I used initially, the fsbl failed to do proper handoff:

 

 

    the_ROM_image:
      {
        [fsbl_config]             r5_single
        [bootloader] fsbl.elf
        [destination_device=pl] zynqpl.bit
        [destination_cpu=a53-0,exception_level=el-3,trustzone] bl31.elf
        [destination_cpu=a53-0,exception_level=el-2] u-boot.elf
        [destination_cpu=a53-0, load=0x80000] linuxImage.bin
        [destination_cpu=a53-0, load=0x4000000] linux-device-tree.dtb
        [destination_cpu=a53-0, load=0x4100000] uramdisk.image.gz

// With these load up here, my R5 is not started properly:
[load=0x1000000] uEnv.txt [load=0x1001000] bootversion.txt
[destination_cpu=r5-0] MyBareMetalR5App.elf

// Down here is good:
// [load=0x1000000] uEnv.txt
// [load=0x1001000] bootversion.txt }

When the fsbl got to do the handoff it simply said:

 

================= In Stage 4 ============
Protection configuration applied
CPU 0x100 reset release, Exec State 0x0, HandoffAddress: FFFEA000
Running Cpu Handoff address: 0x0, Exec State: 0
Exit from FSBL
NOTICE:  ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.2(release):a9e3716
NOTICE:  BL31: Built : 13:55:16, Nov  8 2016

That is, with the Cpu Handoff address at 0x0.

 

However, if I move the two "load" lines with my txt files from above the R5-app-line down under the R5-app-line, things work as expected:

 

================= In Stage 4 ============
Protection configuration applied
CPU 0x100 reset release, Exec State 0x0, HandoffAddress: FFFEA000
Running Cpu Handoff address: 0x200002D0, Exec State: 8
Exit from FSBL
NOTICE:  ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.2(release):a9e3716
NOTICE:  BL31: Built : 13:55:16, Nov  8 2016

Is this a known limitation or do I need to spice my bif-file with some more parameters?

 

BR,

Martin

 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
8,633 Views
Registered: ‎03-13-2012

Re: [2016.3, Zynq MPSoC, FSBL] Fsbl handoff bug/understanding when "load" lines in boot.bif are shuffled?

Jump to solution

I'm just guessing, but my guess is:

Order of the partitions in the bif matter. E.g. for the APU files, you must have bl31 listed first to ensure that the handoff on the APU happens to the ATF instead of any of the other images.

I'm not sure what exactly happens in your case, but I suspect that not specifying a destination CPU might result in a default of R5-0 and listing the u-boot files before the bare metal app would then result in the FSBL interpreting the partition with uEnv.txt as the R5 application to hand off to. And since the txt/binary doesn't have any entry-point information, that probably defaults to 0.

In case that theory holds, I suspect you could alternatively also annotate the two txt file partitions with '

destination_cpu=a53-0 

to get around this.

2 Replies
Xilinx Employee
Xilinx Employee
8,634 Views
Registered: ‎03-13-2012

Re: [2016.3, Zynq MPSoC, FSBL] Fsbl handoff bug/understanding when "load" lines in boot.bif are shuffled?

Jump to solution

I'm just guessing, but my guess is:

Order of the partitions in the bif matter. E.g. for the APU files, you must have bl31 listed first to ensure that the handoff on the APU happens to the ATF instead of any of the other images.

I'm not sure what exactly happens in your case, but I suspect that not specifying a destination CPU might result in a default of R5-0 and listing the u-boot files before the bare metal app would then result in the FSBL interpreting the partition with uEnv.txt as the R5 application to hand off to. And since the txt/binary doesn't have any entry-point information, that probably defaults to 0.

In case that theory holds, I suspect you could alternatively also annotate the two txt file partitions with '

destination_cpu=a53-0 

to get around this.

Visitor egholm
Visitor
4,647 Views
Registered: ‎05-13-2016

Re: [2016.3, Zynq MPSoC, FSBL] Fsbl handoff bug/understanding when "load" lines in boot.bif are shuffled?

Jump to solution

Hi Søren,

 

Indeed, that also did the trick.

So it seems your assumption about the partition order holds.

 

Thanks again.

 

And hopefully the existence of the above log entries can save some hours for others :)

 

BR,

Martin

0 Kudos