Enable proxyclient operations on A7-A11, T2 SoCs.

[asdfugil]

This PR enables the proxyclient to be used through the physical UART on A7-A11, T2 SoCs.

On A7-A11, the default frequency is too slow for baudrate 1500000, so change the CPU frequency before going into that baud rate. (T2 default frequency is fast enough)

Support the PMU in A7-A10X, which is over I2C, and the PMU in A11, T2, which is over "spmi,gen0" SPMI. In either case, the panic counter does not seem to exist.

Finally, add support for /arm-io/pmgr with 8-bit IDs. Do note that any hypervisor modifications are not tested.

[asdfugil]

Of course, many scripts still don't work. This obviously includes hypervisor and cpu_pstate_latencies.py, but even the mmio_sweep.py modified here don't exactly work properly either. It is modified to not break M1. pmgr_adt2dt.py and dump_pmgr.py do work after the modifications though.

[asdfugil]

Changes: Support A7-A11, T2 PMU instead of skipping the setup. The reset counter still does not apply however. It might apply, need to check as more research is conducted.

[svenpeter42]

I'd just pull all the logic for checking the chipid into python here and just call proxy.cpufreq_init if required then

[asdfugil]

detecting the chip id in python means pulling the whole adt over 115200 baud which is really slow. It varies depending on firmware but it could take more than 30 seconds.

[jannau]

you could add a proxy command to request the chipid from m1n1. That's generic and might be useful for other use cases.
Is there a reason why it can't be done on C side in the P_SET_BAUD handler?

[asdfugil]

I think cpufreq adjustment can be in the P_SET_BAUD handler, but then the cases needed to be tested for explodes for all the different baud rates and chips (and that way set baud actually does more than set baud), so I suppose requesting chipid is the way to go.

[asdfugil]

refactored to add P_GET_CHIPID to the proxy and move bulk of the logic to the python side. Drive by fix for P_EL3_CALL because it is right next to the code being added.

[asdfugil]

on t6000 the upmc is handled correctly (at least as correctly as before) in the hv as well
triggered by accessing the UPMC registers in guest m1n1

TTY> [FIQ] UPMC IRQ, masking  == Exception taken from EL1h ==
  SPSR   = 0x80000005 (N=1, Z=0, C=0, V=0, TCO=0, DIT=0, UAO=0, PAN=0, SS=0, IL=0, SSBS=0, BTYPE=0, D=0, A=0, I=0, F=0, M=0x5(EL1h))
  ELR    = 0x10019727b6c (0x10019727b6c)
  SP_EL1 = 0x100197fbe70 (0x100197fbe70)
    x0-x3 = 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    x4-x7 = 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
   x8-x11 = 0000000000140001 0000000000000000 00000d00241b4000 0000000000000e64
  x12-x15 = 0000000000000000 0000000000000013 0000000000000012 0000000000000012
  x16-x19 = 0000000000000000 0000000000000000 00000000fffffff7 00000100197c8040
  x20-x23 = 0000000000000001 00000100197fbec8 0000000000000000 00000100197ceca8
  x24-x27 = 00000000addedbad 0000000000aa55ff 00000100197cecac 00000100197fbee8
  x28-x30 = 00000000addedbad 00000100197fbe70 0000010019727a2c

  == Code context ==
  10019727b5c: f9000109  	str	x9, [x8]
  10019727b60: d5033f9f  	dsb	sy
  10019727b64: 2a1f03e0  	mov	w0, wzr
  10019727b68: d5033fdf  	isb
 *10019727b6c: b9000274  	str	w20, [x19]
  10019727b70: a9434ff4  	ldp	x20, x19, [sp, #0x30]
  10019727b74: f9400bf7  	ldr	x23, [sp, #0x10]
  10019727b78: a94257f6  	ldp	x22, x21, [sp, #0x20]
  10019727b7c: a8c47bfd  	ldp	x29, x30, [sp], #0x40

really it should be passed to the guest but the old behavior does not do that so whatever