armstub7: Major refactoring and size improvements

[fincs]

My motivation for this PR is #114 (comment), pointing out a critical lack of space in the armv7 bootstub which is preventing new features and bugfixes from being implemented. Here's a summary of the changes (I might have missed some, though):

• The bootstub has been completely rewritten taking advantage of the Thumb-2 instruction set, which results in major space gains
• Res0 bits of NSACR are no longer set (supersedes armstub7: Various fixes #85)
• CNTVOFF is set to zero, now consistent with armstub8 (supersedes armstub7: Also reset CNTVOFF #113)
• SMC instructions are now disabled, now consistent with armstub8
• ACTLR is now configured to allow Non-secure access to several CPU configuration registers (CPUACTLR/CPUECTLR/L2CTLR/L2ECTLR/L2ACTLR), which makes it possible to e.g. enable Spectre v4 mitigations directly in the kernel without needing a separate bootstub variant (potentially supersedes add Cortex-A72 Spectre v4 (CVE-2018-3639) mitigation #115); armstub8 also updated to configure ACTLR in the same way

The free space in each bootstub built from armstub7.S is now as follows:

armstub7.bin:        108 bytes
armstub8-32.bin:     104 bytes
armstub8-32-gic.bin:  44 bytes (!)

Successful testing has been carried out on Raspberry Pi 2 (original revision with Cortex-A7), Pi 3, as well as Pi 4; respectively.

I'm also providing the raw disassembly of these stubs, in case anyone is curious about it.

Any further comments (such as pointing out mistakes I might have introduced) are very much appreciated.

[pelwell]

Sorry it's taken a while to get round to looking at this PR. I'm still working through the code, but it's at least booted successfully on a variety of devices.

One thing that bothers me is the setting of the SMD bit as part of the secure monitor call. Since there is one smc instruction in the stub, does that mean that once the stub hands over to the "kernel" that no other smc calls are allowed? How does that affect U-boot which the now-deleted comment claims uses smc?

[fincs]

No worries, I imagine with the current events it's difficult to find time/resources for anything.

Since there is one smc instruction in the stub, does that mean that once the stub hands over to the "kernel" that no other smc calls are allowed?

That is correct, SMC instructions are no longer allowed when using the stub. This makes it consistent with the 64-bit stub, which has never allowed SMCs either.

How does that affect U-boot which the now-deleted comment claims uses smc?

I was puzzled by the comment as well, but after some digging I discovered it was just copypasted from u-boot's own SMC handler. I believe u-boot does not use SMC on Raspberry Pi, as that would require loading a "kernel" into address 0 (which would bypass the armstub, so even if it does this change doesn't affect it anyway). I haven't found any evidence of CONFIG_ARMV7_NONSEC being enabled on Raspberry Pi either (which is what causes SMC related code to be included in u-boot).

[pelwell]

Thanks - that makes a lot of sense.

I'll probably look at it for a bit longer, trying to pretend I understand it all, then merge it.

[pelwell]

Any concerns, @popcornmix?

[popcornmix]

Let's give it a try. The extra space will be nice to have.

[pelwell]

I'll grab the generated header for the firmware.

[pelwell]

And thank you!