LS1046A: u-boot hangs transferring control to Linux. Exception? How to disable security?

[AbelianMeme]

Hi Everyone,

I am trying to get u-boot to boot Linux on our custom PCB with an LS1046a. (U-boot v. 2018.03 - the same one used in the lsdk) The issue is that everything simply "hangs" after issuing the booti instruction. I have traced the problem down to "armv8_switch_to_el2_m" (macro.h) called from transition.S. U-boot correctly loads the address of the Linux binary into ELR_EL3, then calls eret, which should result in the processor switching to EL2 and transferring control to Linux.

Unfortunately, execution never makes it to the first instruction on the Linux binary. (At address 0x8108_0000 in DDR RAM) So the likely scenario is that u-boot is taking an exception, but I can not see any exception traps taken. A data point that I have, is the u-boot macro above is setting SCR_EL3 to the following value before the eret:

SCR_EL3_RW_AARCH64 | SCR_EL3_HCE_EN | SCR_EL3_RES1 | SCR_EL3_NS_EN

However, if I remove SCR_EL3_NS_EN and leave the other 3 flags, then I do get an immediate "Synchronous Abort" as soon as the eret is issued.  This leads me to believe the issue may be related to the security manager.

Now, I do not need security on this project, so I have not configured the TZC400, nor have I loaded any security firmware. I am not sure what u-boot does with this by default, but I haven't changed any of it's default behavior.

I have 2 questions:

1. What do I need to do in order to guarantee the security manager is completely disabled and can not be responsible for the issue above?

2. Are there any other issues anyone is aware of which might be causing the behavior I am seeing?

[AbelianMeme · Accepted solution]

This solution is a little late. Our project got held up due to the chip shortage and the inability to spin a new PCB. For anyone who may have the same issue, the issue was that u-boot 2018.03 is hopelessly broken.  We switched to u-boot 2021.04 and it is working fine.

[AbelianMeme]

An update to this. The Synchronous Abort exception I get when I remove the SCR_EL3_NS_EN from SCR_EL3 before issuing the eret results in an "Illegal Execution state" exception (esr = 0x3a000000). Since there are no unaligned accesses, and FAR_EL3 reads as zero, I have no more information. It is not clear to me why telling the processor that EL0 and EL1 are trusted should generate an "Illegal Execution State". But this may be a red herring as it does not seem to be helping me to understand where the processor is going when it hangs.

[AbelianMeme]

Just another update on this problem. The jump_to address passed to the EL3->EL2 routine makes no difference. It is not an issue with DDR RAM. I poked an illegal instruction (0xf7f0a000) into OCRAM, then passed the address of the illegal instruction in OCRAM to armv8_switch_to_el2.  The processor still hangs. It never reaches ANY exception vectors. I have them all trapped. So where does it go?  I have no idea.  Based on the power consumption I can see it is running hot, so where ever it is the cores are spinning. If anyone has any thoughts on how this could be happening I am open to suggestions.

[JRRandall]

Just curious if you got further in debugging this?  We might be having a similar issue on our LS1046A-based custom board.

[Pavel]

Test your board using bootm command and Linux image in .itb file.