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]

Message-Id: <e04cf26e-2e38-4e87-b7b4-23dafadee00d@app.fastmail.com>
Date:   Mon, 14 Aug 2023 15:41:37 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Yinbo Zhu" <zhuyinbo@...ngson.cn>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "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

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?

>>>> 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?

      Arnd