lkml.org 
[lkml]   [2023]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm
From
Date


在 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

\
 
 \ /
  Last update: 2023-08-14 14:00    [W:0.062 / U:1.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site