How to boot BL33 with EL1

[m_kei]

I am currently using LX2160ARDB_REV2 to develop an RTOS to run on EL1.

The LSDK firmware has an Exception Level of EL2 at the time of BL33 (U-Boot) startup, so in order to run the RTOS, the firmware needs to be changed so that BL33 boots at EL1.

Based on "Layerscape Software Development Kit User Guide", we can now generate fip.bin, bl2_sd.pbl, and fip_ddr_all.bin.
In the default state, I can boot from the SD card without any problems, but as mentioned above, BL33 boots at EL2.

So I looked for a place that sets the EL for BL33 startup, and found something like that in "ls_get_spsr_for_bl33_entry()" in "atf/plat/nxp/common/setup/ls_bl2_el3_setup.c".
Here it looks like we are setting the SPSR for BL33 startup.

mode = (el_implemented(2) != EL_IMPL_NONE) ? MODE_EL2 : MODE_EL1;

 I rewrote the relevant part as follows.

mode = MODE_EL1;

After making the changes, SW stops after the following log output at startup.

NOTICE:  BL2: v2.4(release):LSDK-21.08-0-g340b20bcb-dirty
NOTICE:  BL2: Built : 18:54:19, Jan 14 2022
NOTICE:  UDIMM xxx
NOTICE:  DDR PMU Hardware version-0x1210
NOTICE:  DDR PMU Firmware vision-0x1001 (vA-2019.04)
NOTICE:  DDR4 UDIMM with 2-rank 64-bit bus (x8)

NOTICE:  32 GB DDR4, 64-bit, CL=22, ECC on, 256B, CS0+CS1
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.4(release):LSDK-21.08-0-g340b20bcb-dirty
NOTICE:  BL31: Built : 18:54:13, Jan 14 2022
NOTICE:  Welcome to lx2160ardb BL31 Phase

One thought is that U-Boot may be prevented from booting on EL1.
However, the U-Boot that I used to use worked regardless of EL1/EL2, and if the LSDK U-Boot does not work with EL1, I think it is doing something special.

Do you have any idea what this means?

[yipingwang · Accepted solution]

According to customer's test, the system hung at the uboot phase For the u-boot itself, it could be used under both EL2 and EL1, even EL3(if no ATF or other EL3 firmware involved) However, from NXP LSDK aspect, current implementation is: ATF(EL3) --> u-boot(EL2)--->Linux kernel(EL1), the LSDK developer did not develop for making U-boot worked under EL1 in LSDK, it is not supported in LSDK implementation.

As a result, since the LSDK design is using uboot under EL2, so that maybe there are some code related with the EL2 registers or need running under EL2, it could be possibly main reason of the customer's test result If the customer have to use the u-boot under EL1, our suggestion is fully going through the whole code, checking if there are EL2 dependency code, then modify it carefully to adapt to the EL1 level, then theoretically the uboot could be used under EL1