When I first began working with this chip, it was unknown to me whether the cores boot up in 32 bit or 64 bit mode. Now I know that they start up in 64 bit mode and the bootrom is coded to run 64 bit from the very start.
Examination of the midr_el1 register indicates the first core allowed to run is an A53 core. The contents of this register are 410FD034, which can be interpreted as follows:
41 = maker is ARM
0 = major revision number
f = architecture (presumably armv8 ?)
d03 = A53 core
4 = minor revision number
So this is an A53 core of revision r0p4.
If we saw d08 rather than d03 it would be an A72 core.
How it comes out of reset is entirely a matter of how the SoC was designed. It could have been done either way and could even be different for the a53 versus the a72 cores. It must not be, since both will enter the bootrom and the bootrom is entirely 64 bit code.
Unsurprisingly then, U-Boot runs in 64 bit mode and passes control to my code in 64 bit mode. There are other questions about EL (execution level) as well as how secure mode is handled that I have yet to answer. U-Boot runs at el2 in non-secure mode. It is not clear if U-Boot drops itself to el2 when it starts up, or if that is done by BL31.
I will note that something called BL31 runs before U-Boot and announces:
BL31: Preparing for EL3 exit to normal world
At first I was going to avoid digging into bootup issues, but curiosity has driven me into that rabbit hole. I could have ignored it all, given that it is all working fine, U-Boot runs, and does network booting for me. But we do all this for satisfaction and perhaps you could say entertainment.
Tom's electronics pages / tom@mmto.org