cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
10,571 Views
Registered: ‎05-13-2016

[2016.3, ZynqMP, zcu102] Wrong exception level in ATF/BL31 after FSBL handoff?

Jump to solution

Hi,

 

I'm trying to build FSBL (2016.3) from GIT (https://github.com/Xilinx/embeddedsw) following the steps from the README.txt.

I'm running on the zcu102 board, so that should be a matter of just following the few steps there.

 

That is:

$ source /opt/Xilinx/SDK/2016.2/settings64.sh
$ make clean
$ make "CFLAGS+=-DFSBL_DEBUG_INFO"

 And in order for the new version of the FSBL to work, I need update the ATF/BL31, as well.

So I just followed http://www.wiki.xilinx.com/Build+ARM+Trusted+Firmware+(ATF) and cloned https://github.com/ARM-software/arm-trusted-firmware 

 

So:

$ make clean
$ make PLAT=zynqmp RESET_TO_BL31=1 LOG_LEVEL=50

 

I have a boot.bif that worked with 2016.1 versions of BL31 and FSBL, replacing those two files with the artifacts coming out of the above, is no good. I get a complaint from BL31 about exception level being wrong:

 

 

================= In Stage 4 ============
Protection configuration applied
Running I       =M Xilinx IDCODE 0x4738093
NOTICE:  ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000
VERBOSE: Generic delay timer configured with mult=1 and div=100
VERBOSE: BL31: ATF handoff params at:0xfffe9e00, entries:2
VERBOSE: BL31: 0: entry:0xfffea000, flags:0x0
WARNING: BL31: invalid exception level (0)
VERBOSE: BL31: 1: entry:0x8000000, flags:0x0
WARNING: BL31: invalid exception level (0)
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x0

The two entries (0xfffea000 and 0x8000000) seem correct, but their flags not so much.

 

Any ideas for getting me in right direction is appreciated :)

 

BR,

Martin Egholm

 

0 Kudos
Reply
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
16,091 Views
Registered: ‎03-13-2012

Since 2016.3 we support a more dynamic handoff approach that depends on FSBL passing arguments to the ATF (https://github.com/Xilinx/arm-trusted-firmware/commit/b96f77c65ba5 ).

For the FSBL to populate the argument structure correctly, it in turn depends on the correct attributes being provided through the boot image. Most likely, your issue goes away once you update your '.bif' file similar to this example (notice the 'trustzone' and 'exception_level' partition attributes):

the_ROM_image:
{
    [fsbl_config] a5x_x64
    [pmufw_image] xpfw.elf
    [bootloader] fsbl.elf
    [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,exception_level=el-1,trustzone] bl32.elf
}

View solution in original post

4 Replies
Visitor
Visitor
10,542 Views
Registered: ‎05-13-2016

Just following up on my own post:

Scanning the code, it seems that "all" this exception level "discrimination" is a new feature in the ATF since 2016.2.

 

Going back to 2016.2 source for both ATF and FSBL things work as expected.

 

So I reckon I must be missing some build parameters or something when trying to build 2016.3 versions.

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
16,092 Views
Registered: ‎03-13-2012

Since 2016.3 we support a more dynamic handoff approach that depends on FSBL passing arguments to the ATF (https://github.com/Xilinx/arm-trusted-firmware/commit/b96f77c65ba5 ).

For the FSBL to populate the argument structure correctly, it in turn depends on the correct attributes being provided through the boot image. Most likely, your issue goes away once you update your '.bif' file similar to this example (notice the 'trustzone' and 'exception_level' partition attributes):

the_ROM_image:
{
    [fsbl_config] a5x_x64
    [pmufw_image] xpfw.elf
    [bootloader] fsbl.elf
    [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,exception_level=el-1,trustzone] bl32.elf
}

View solution in original post

Visitor
Visitor
10,510 Views
Registered: ‎05-13-2016
Hi Søren,

That sounds very much like the solution! Will try that Monday morning. Thanks!

Martin
0 Kudos
Reply
Visitor
Visitor
10,455 Views
Registered: ‎05-13-2016
Hi Søren,

As expected, that did the job. Thanks a bunch.

Martin
0 Kudos
Reply