linux-kernel - Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2023 12:08:39 +0800
From:   Yinbo Zhu <zhuyinbo@...ngson.cn>
To:     Arnd Bergmann <arnd@...db.de>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        zhuyinbo@...ngson.cn, Conor Dooley <conor+dt@...nel.org>,
        linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, soc@...nel.org,
        Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Jianmin Lv <lvjianmin@...ngson.cn>, wanghongliang@...ngson.cn,
        Liu Peibao <liupeibao@...ngson.cn>,
        loongson-kernel@...ts.loongnix.cn, loongarch@...ts.linux.dev,
        Liu Yun <liuyun@...ngson.cn>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm



在 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