Received-SPF: pass (google.com: domain of linux-kernel+bounces-92752-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <tencent_3638D6E106C784859837E6F3C10BDA688F0A@qq.com>
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb
 dts
From: Yangyu Chen <cyy@cyyself.name>
In-Reply-To: <20240305-shorten-disallow-eae65fdc8fdb@spud>
Date: Wed, 6 Mar 2024 01:17:29 +0800
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
 linux-riscv@lists.infradead.org,
 Damien Le Moal <dlemoal@kernel.org>,
 Rob Herring <robh+dt@kernel.org>,
 krzysztof.kozlowski+dt@linaro.org,
 Paul Walmsley <paul.walmsley@sifive.com>,
 Albert Ou <aou@eecs.berkeley.edu>,
 guoren@kernel.org,
 devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
References: <mhng-f1aa91d4-211f-4eb4-a94d-a9d88b0d3f6a@palmer-ri-x1c9>
 <7A86D933-B85F-4B29-8D6D-AB414A42AC06@cyyself.name>
 <tencent_B2C1146D4947315C8018AE90EDC64F3E6207@qq.com>
 <20240305-shorten-disallow-eae65fdc8fdb@spud>
To: Conor Dooley <conor@kernel.org>


> On Mar 6, 2024, at 01:01, Conor Dooley <conor@kernel.org> wrote:
>=20
> Hey,
>=20
> Just chiming so that things don't get misinterpreted.
>=20
> On Wed, Mar 06, 2024 at 12:37:16AM +0800, Yangyu Chen wrote:
>>> On Mar 6, 2024, at 00:22, Yangyu Chen <cyy@cyyself.name> wrote:
>>>> On Mar 5, 2024, at 23:54, Palmer Dabbelt <palmer@dabbelt.com> =
wrote:
>>>> On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
>>>>> - Svpbmt and T-Head MAEE both supported
>>>>>=20
>>>>> T-Head C908 does support both Svpbmt and T-Head MAEE for =
page-based memory
>>>>> attributes and is controlled by csr.mxstatus. If the kernel wants =
to use
>>>>> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to =
zero
>>>>> before entering the s-mode kernel. Otherwise, the kernel will not =
boot as 0
>>>>> on T-Head MAEE represent to NonCachable Memory and it will lose =
dirty cache
>>>>> lines modification that haven't been written back to the memory.
>>>>=20
>>>> So I guess we need the bootloader to just be accurate here?  ie: =
whatever
>>>> extension it tells S-mode kernels is enabled is how S-mode behaves, =
and
>>>> then this should just work itself out.
>=20
> Correct, the bootloader/firmware "just" needs to write this bit to =
match
> what it passes to onwards in the devicetree.
>=20
>>> Yes. Currently, I have patched OpenSBI to disable MAEE. Conor Dooley =
said
>>> from a public irc group that he wants to control the enable of =
T-Head
>=20
> (#riscv on libera, the usual location)
>=20
> I also suggested that that, given we can use the standard extensions,
> we should use them instead of the custom extensions/errata.
>=20
>>> variation of zicbom and svpbmt from dts, in addition to mimplid or
>>> something now.
>=20
> Correct. I'm find with the impid =3D=3D archid =3D=3D 0 condition, =
given that's
> what we need to keep to avoid regressions, but if any future T-Head =
CPUs
> want to enable MAEE (ERRATA_THEAD_PBMT) or the custom CMOs
> (ERRATA_THEAD_CMO) these should be enabled from DT. Particularly when
> these CPUs can be configured to either use the T-Head versions or the
> standard extensions.
>=20
>>> I think that will be a better way for the bootloader to tell
>>> the kernel whether the T-Head MAEE should be enabled.
>=20
> You've got three options I guess. You could patch the DT in the =
bootloader,
> or use a fixed DT that matches the bootloader, or you could use the DT
> passed to the bootloader and parse the extensions to decide whether or =
not
> to enable MAEE or Svpbmt. Seems you're going for option 2.
>=20

The patched opensbi is only for work around now as the factory-provided
M-Mode uboot will enable MAEE. I would like option 1 to let the =
bootloader
choose what to use and patch the DT to tell the linux whether should use
T-Head MAEE as T-Head is likely to use this feature on TEE
(Trusted Execution Environment), so it might never be removed.

>>> Link: =
https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031=
a9399354
>>>=20
>>> Furthermore, I wonder whether a CPU node like this would be =
acceptable.
>>> I don't have any other details of how another CPU from K230 SoC =
works on
>>> Linux.
>=20
> A CPU node like what? It is not clear to me.

It in the k230.dtsi file. Only has big core there.