Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm
From: Yinbo Zhu
Date: Tue Aug 15 2023 - 00:16:03 EST
在 2023/8/14 下午9:41, Arnd Bergmann 写道:
On Mon, Aug 14, 2023, at 13:57, Yinbo Zhu wrote:
在 2023/8/14 下午4:19, Arnd Bergmann 写道:
On Mon, Aug 14, 2023, at 09:57, Yinbo Zhu wrote:
在 2023/8/12 下午8:25, Arnd Bergmann 写道:
I found https://github.com/loongson-community/pmon source
code, and a reference to its origin at LSI Logic at
https://www.linux-mips.org/wiki/PMON but otherwise have
no idea about what this actually is, or how it relates
to your UEFI firmware. Did you add UEFI support to PMON,
or do you use it as a first stage loader that loads
the actual UEFI implementation (EDK2 or u-boot, I guess)?
Pmon and uefi are two different firmware, and there is no connection
between them.
It sounds like we still have problems with terminology. >
I don't think categorizing UEFI as a firmware is correct,
Sorry to have confused you, uefi firmware is our internal name, which is
actually what you referred to as EDK2, the EDK2 need use UEFI.
Ok
it's the interface used by various firmware implementations
to load the operating system. As far as I understand,
loongarch currently mandates the use of UEFI in whichever
firmware is used, so if you have Pmon installed in ROM > and Pmon does not itself implement UEFI, it would have
to load some other firmware such as u-boot in order to
load a kernel through the UEFI protocol, right?
PMON is an independent firmware and loader that can directly load the
operating system and it does not require the use of UEFI.
Has the assumption that loongarch requires UEFI changed?
LoongArch embedded board was use Pmon firmware, The other one uses UEFI
firmware (EDK2) on LoongArch platform.
I'm pretty sure we discussed this when the loongarch port
was originally merged, with the decisionto just use UEFI for
booting any kernel, as the legacy entry point for the ACPI
based environment was not really well-defined and the UEFI
stub was an easy alternative to have more commonality
with other architectures.
I see this was already extended for embedded CPUs to use
the uefi stub with DT in commit 88d4d957edc70 ("LoongArch: Add
FDT booting support from efi system table"), which seems like
the right direction. >
Can you explain why this board would want yet another method
for entering the kernel? Is there any documentation for the
boot protocol?
Yes, you're right, the latest PMON does indeed support UEFI, the PMON
used in the product code is still outdated and does not support UEFI.
Actually, whether using EDK2, Pmon firmware, or other firmware, the
LoongArch platform's s3 (suspend-to-ram) requires a suspend-address to
be defined, if dts is supported, it is defined in dts, and if acpi table
is supported, it is defined in acpi table.
Is this executing directly from ROM then?
Yes.
Is this the only runtime call into the firmware,
Only when suspend-to-ram occurs, the kernel will call into the firmware.
No other case.
Ok
or are there
others that are either already called from mainline kernels
or in your downsteam implementation?
How do you ensure that the DTB matches the actual ROM code
after rebuilding Pmon? Does Pmon itself fill that field with
the correct address, or do you rely on it being a hardcoded
constant?
Use Pmon, firmware team will always ensure that DTB matches the actual
ROM code. The "suspend-address" of dtb and pmon entry address will
synchronized modification by firmware team.
Ok. So it's linked against libfdt to fill the dtb information,
or do you have to provide a dtb blob that matches the firmware?
For pmon firmware, the dtb was as part of firmware, the firmware has
defined the address of the DTB's suspend and the address of the firmware
entry, and is consistent.
Thanks,
Yinbo