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

[egholm]

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

[egholm]

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.

[sorenb · Accepted solution]

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
}

[egholm]

Hi Søren,

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

Martin

[egholm]

Hi Søren,

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

Martin