Hi Maxim, There could be some terminology mixup that needs to be clarified. These are the typical words related to boot in TF-A:
1. cold boot : This is the first boot after a power cycle. Typically a single CPU is powered up and executed the entire boot flow upto linux 2. Warm boot: The Cold boot has completed and transitioned into Linux kernel and then the kernel invokes PSCI_CPU_ON to power up the secondary CPUs. This is the CPU `hotplug` operation from linux side.
The figure you referred to mentions these boot scenarios.
Now reboot is system reset + cold boot. Ideally if QEMU has to support reboot, it needs to be able to reset the system (CPUs and peripherals) from software. The flow you suggest for QEMU could work but if the CPU and the peripherals are not reset properly, you could encounter errors later on because software could assume reset values for some registers and hence may not initialize it. Also there are registers that are 1 time write and cannot be written to again without proper reset cycle, and these could problems during execution.
Best Regards Soby Mathew
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Maxim Uvarov via TF-A Sent: 24 September 2020 13:27 To: Maxim Uvarov maxim.uvarov@linaro.org Cc: tf-a@lists.trustedfirmware.org; Ilias Apalodimas ilias.apalodimas@linaro.org; Arnd Bergmann arnd@linaro.org Subject: Re: [TF-A] TF-A warm reboot question
sorry, wrong email thread.
Another way around is to not support "hot reset" in ATF, but make qemu reboot is implement some watchdog for qemu virt platform. That also works for me with quick implementation with lhe link which I sent in the previous email.
Maxim.
On Thu, 24 Sep 2020 at 15:16, Maxim Uvarov via TF-A <tf- a@lists.trustedfirmware.org> wrote:
I.e. that implementation works for me:
https://github.com/muvarov/qemu/commit/f5e3fb83170613a9eed46b87358 ab2e
37de260a2
On Mon, 21 Sep 2020 at 18:16, Maxim Uvarov maxim.uvarov@linaro.org
wrote:
Hello,
I'm trying to understand why "warm reboot" is not currently implemented in TF-A for qemu targets. I.e. in case of qemu armv8 boot atf->optee->uboot->linux and then reboot, cpu jumps to BL31 qemu_system_reset() function which just calls panic(). I'm wondering why loading images from this stage is not happening? Something similar to bl2_load_images()->load_image() to load uboot and optee os again and run them with bl31_main()?
If I understand "CPU reset" spec [1] correctly, warm boot from reset vector in BL31 again to Non-Secure world has to work.
firmware/blob/master/doc
s/design/reset-design.rst
Best regards, Maxim.
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a