Messages in this thread | | | Subject | Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm | From | Yinbo Zhu <> | Date | Mon, 14 Aug 2023 19:57:51 +0800 |
| |
在 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 写道: >>> On Fri, Aug 4, 2023, at 04:54, Yinbo Zhu wrote: >>>> 在 2023/8/3 下午3:44, Arnd Bergmann 写道: >>>>> On Thu, Aug 3, 2023, at 08:37, Yinbo Zhu wrote: >>>> >>>>> Is this some SRAM that needs to execute the suspend logic >>>>> in order to shut down memory and cache controllers? >>>> >>>> >>>> Yes, The suspend-to-ram after into pmon firmware code and set >>>> self-refresh mode in memory controller and ensure that memory data is >>>> not lost then shut down memory controller. >>> >>> I'm sorry I missed your reply earlier, getting back to the >>> thread now. So it's clear that this code needs to run in a >>> special memory from your description, but I'm still trying >>> to understand the details better. >>> >>> 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.
> 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.
> >>>>> Or is >>>>> this a runtime firmware interface similar to how UEFI handles >>>>> its runtime services to keep the implementation out of >>>>> the kernel? >>>> >>>> >>>> No, The main cpu and other cpu will offline that after into firmware and >>>> finished Corresponding operations, the pmon firmware will not run. >>> >>> I'm still trying to understand your explanations here. >>> You say that pmon no longer runs, but that seems to contradict >>> what you said earlier about branching into pmon firmware code >>> for suspend. >> >> >> It's not contradictory. The suspend-to-ram is that from kernel goto to >> pmon firmware code, then pmon finished corresponding operations, which >> was to set self-refresh mode in memory controller, then memory HW will >> maintain its own data and no longer requires software processing, pmon >> firmware will not run. > > That is what I mean with a "runtime firmware interface", i.e. you > jump into firmware in order to request services from it. Clearly the > firmware itself does not run while the OS is executing code, but it is > still there and waiting to be called here, which is similar to > things like UEFI runtime services, PowerPC RTAS, Arm EL3/trustzone > based firmware or x86 SMM firmware, except that this is much less > formalized and only consists of an entry point with undocument > calling conventions. > >>> 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.
> 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.
Thanks, Yinbo
| |