qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 05/16] hw/arm: allwinner: Don't enable PSCI conduit when boot


From: Samuel Holland
Subject: Re: [PATCH 05/16] hw/arm: allwinner: Don't enable PSCI conduit when booting guest in EL3
Date: Wed, 2 Feb 2022 15:11:45 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 1/31/22 4:52 AM, Andre Przywara wrote:
> On Sun, 30 Jan 2022 23:35:37 +0100
> Niek Linnenbank <nieklinnenbank@gmail.com> wrote:
>> On Thu, Jan 27, 2022 at 4:46 PM Peter Maydell <peter.maydell@linaro.org>
>> wrote:
>>> If anybody knows for definite that the secondaries should be
>>> powered-down at startup for guest firmware, we can delete the TODO.
>>
>> Looking at the Allwinner H3 datasheet in 4.4.3.7 page 146, it says that
>> for the CPU1 Status Register the default value indicates at least that its
>> not in a
>> wait for interrupt standby mode. And if I look in U-Boot's
>> arm/arm/cpu/armv7/sunxi/psci.c code
>> in the psci_cpu_on implementation, there is an explicit 'power on' part
>> there, suggesting the secondary CPUs
>> are by default off. So while I don't have any hard proof, these findings
>> suggest we are modeling the correct behavior
>> with secondary CPUs by default off.
> 
> So when it comes to firmware, indeed the secondaries seem to be off when
> the first user provided code (boot0/SPL) is entered. However there is an
> MPIDR read in the BROM, with the corresponding "branch if not primary
> core". I think this is because the BROM is mapped at the reset vector, so
> upon SMP firmware releasing the reset line it always starts in ROM, then
> gets diverted to the actual entry point.

Yes, I believe this is an accurate explanation.

> Maybe Samuel can confirm that the secondary cores are power gated when the
> SoCs comes out of reset?

The secondary cores are powered up but held in reset, as described in the
datasheet (sections 4.4.3.5/8/11 "CPU1/2/3 Reset Register"). The boot ROM does
not touch any of the CPU Configuration registers, so they hold their default
values into U-Boot execution. Looking at the registers from the U-Boot shell
confirms the datasheet:

=> md.l 1f01500 20
01f01500: 00000000 00000000 00000000 00000000  ................
                 ^ output gating[0] is disabled for all CPUs
01f01510: 00000000 00000000 00000000 00000000  ................
01f01520: 00000001 00000000 00000000 00000000  ................
01f01530: 00000000 00000000 00000000 00000000  ................
01f01540: 00000000 00000000 00000000 00000000  ................
                ^^       ^^       ^^       ^^
                power switches[1] are enabled for all CPUs
01f01550: 00000000 00000000 00000000 00000000  ................
01f01560: 00000000 00000000 00000000 00000000  ................
01f01570: 00000000 00000000 00000000 00000000  ................

=> md.l 1f01c40 40
01f01c40: 00000003 00000000 00000001 00000000  ................
                 ^ nCPUPORESET and nCORERESET deasserted
01f01c50: 00000000 00000000 00000000 00000000  ................
01f01c60: 00000000 00000000 00000000 00000000  ................
01f01c70: 00000000 00000000 00000000 00000000  ................
01f01c80: 00000001 00000000 00000000 00000000  ................
                 ^ nCPUPORESET deasserted; nCORERESET asserted
01f01c90: 00000000 00000000 00000000 00000000  ................
01f01ca0: 00000000 00000000 00000000 00000000  ................
01f01cb0: 00000000 00000000 00000000 00000000  ................
01f01cc0: 00000001 00000000 00000000 00000000  ................
                 ^ nCPUPORESET deasserted; nCORERESET asserted
01f01cd0: 00000000 00000000 00000000 00000000  ................
01f01ce0: 00000000 00000000 00000000 00000000  ................
01f01cf0: 00000000 00000000 00000000 00000000  ................
01f01d00: 00000001 00000000 00000000 00000000  ................
                 ^ nCPUPORESET deasserted; nCORERESET asserted
01f01d10: 00000000 00000000 00000000 00000000  ................
01f01d20: 00000000 00000000 00000000 00000000  ................
01f01d30: 00000000 00000000 00000000 00000000  ................

Since these CPU configuration registers are in the "CPUS" (ARISC) power domain,
it is not possible to reset them to their defaults using software. However, on
64-bit SoCs the CPUCFG registers are in the "CPU_SUBSYS" (ARM) power domain, and
they can be fully reset by toggling CPU_SYS_RESET[2][3]. Using A64 as an
example, the default value for the Cluster Reset Control Register 0x11101101,
which also matches the manual (section 3.4.5.8). Again, this has core 0 reset
deasserted and the remaining core resets asserted. So far, this behavior has
been consistent across every Allwinner SoC I have worked with.

Regards,
Samuel

[0]:
https://github.com/crust-firmware/crust/blob/master/platform/h3/include/platform/prcm.h#L55
[1]:
https://github.com/crust-firmware/crust/blob/master/platform/h3/include/platform/prcm.h#L69
[2]:
https://github.com/crust-firmware/crust/blob/master/platform/a64/include/platform/cpucfg.h#L98
[3]:
https://github.com/crust-firmware/crust/blob/master/drivers/css/sun50i-a64-css.c#L24



reply via email to

[Prev in Thread] Current Thread [Next in Thread]