Received-SPF: pass (google.com: domain of linux-kernel+bounces-92840-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_4B189E90E5C66BBE3EC1386D32C715DCF407@qq.com>
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: Resend: Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN
 with MMU for K230
From: Yangyu Chen <cyy@cyyself.name>
In-Reply-To: <tencent_AA20462764AFF185EF405043DBC99119F705@qq.com>
Date: Wed, 6 Mar 2024 02:32:08 +0800
Cc: Damien Le Moal <dlemoal@kernel.org>,
 linux-riscv@lists.infradead.org,
 Rob Herring <robh+dt@kernel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Paul Walmsley <paul.walmsley@sifive.com>,
 Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>,
 Guo Ren <guoren@kernel.org>,
 devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org,
 Conor Dooley <conor.dooley@microchip.com>
Content-Transfer-Encoding: quoted-printable
References: <tencent_BB2364BBF1812F4E304F7BDDD11E57356605@qq.com>
 <tencent_0432DA968E39B81431F921F38D747C008208@qq.com>
 <ef8df22f-dac8-4652-bf17-d10254e6abfb@kernel.org>
 <tencent_E56A833916E00EC7B4840C34FAF1250ADE0A@qq.com>
 <20240305-fascism-enrich-06483ddeb149@spud>
 <tencent_AA20462764AFF185EF405043DBC99119F705@qq.com>
To: Conor Dooley <conor@kernel.org>


> On Mar 6, 2024, at 01:50, Yangyu Chen <cyy@cyyself.name> wrote:
>=20
> The last email was not received in the list due to I didn=E2=80=99t =
change the mode
> to plaintext. Sorry for that. This is a resend email.
>=20
>> On Mar 6, 2024, at 01:20, Conor Dooley <conor@kernel.org> wrote:
>>=20
>> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>>> Since K230 was released, SOC_CANAAN is no longer only referred to =
the K210.
>>>>> Remove it depends on !MMU will allow building dts for K230 and =
remove the
>>>>> K210 string from the help message.
>>>>>=20
>>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>>> ---
>>>>> arch/riscv/Kconfig.socs | 5 ++---
>>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>>>=20
>>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>>> --- a/arch/riscv/Kconfig.socs
>>>>> +++ b/arch/riscv/Kconfig.socs
>>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>>  def_bool SOC_CANAAN
>>>>> config SOC_CANAAN
>>>>> - bool "Canaan Kendryte K210 SoC"
>>>>> - depends on !MMU
>>>>=20
>>>> This seems wrong to me. The k210 support does require no-mmu. So =
why remove
>>>> this ?
>>>=20
>>> It just allows SOC_CANAAN to be selected when MMU=3Dy. With this =
patch,
>>> nommu_k210_defconfig still works.
>>=20
>> I think the concern here is that this would allow people to build a
>> kernel for the k120 with the MMU enabled, not that the existing nommu
>> build will be affected.
>>=20
>=20
> Aha. I don't think is there anyone will try a build with MMU on
> K210. It only has 6MB of memory available to the CPU. For rv64 if
> the S-Mode software starts at 2MB, it will only have 4MB for S-Mode
> Linux. It's hard to trim the kernel and fit in 4MB and even preserve
> some memory for userspace.
>=20
> I also tried to make nommu_k210_defconfig on gcc 13.2.0, it produced a
> 1.6M kernel in arch/riscv/boot/Image. But if I use nconfig to set
> CONFIG_MMU=3Dy and rebuild, the kernel file will increase to 11M.
>=20

Another interesting finding is that the root cause of the huge kernel is
because CONFIG_STRICT_KERNEL_RWX. If we turn it off, the size will
reduced to 1.9M. Not so much for userspace but seems ok to boot.

That is because we defined SECTION_ALIGN to 2MB to fit with one PMD on
rv64 to reduce the miss of TLB. However, it increased the kernel size.

Link: =
https://lore.kernel.org/linux-riscv/d78c601d553dde791057b54252064221f96054=
6e.1586332296.git.zong.li@sifive.com/

I know MMU on K210 is not standard as now.=20

Maybe I should care about that. I will fix this for patch v4.

>> Maybe you could squash in something like the following?
>>=20
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index b4e9b7f75510..75d55059163f 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -72,15 +72,19 @@ config SOC_VIRT
>>  This enables support for QEMU Virt Machine.
>>=20
>> config ARCH_CANAAN
>> - def_bool SOC_CANAAN
>> + bool "Canaan Kendryte SoCs"
>> + help
>> +   This enables support for Canaan Kendryte SoC platform hardware.
>>=20
>> config SOC_CANAAN
>> - bool "Canaan Kendryte SoC"
>> + bool "Canaan Kendryte K210 SoC"
>> + depends on !MMU
>> + depends on ARCH_CANAAN
>> select CLINT_TIMER if RISCV_M_MODE
>> select ARCH_HAS_RESET_CONTROLLER
>> select PINCTRL
>> select COMMON_CLK
>> help
>> -   This enables support for Canaan Kendryte SoC platform hardware.
>> +   This enables support for Canaan Kendryte K210 SoC platform =
hardware.
>>=20
>> endmenu # "SoC selection"
>>=20
>> (Which reminds me, I really need to go and finish sorting out the =
ARCH_
>> stuff)
>=20
> Seems like an idea if we want this consideration. But I don't think we =
need
> this as the opinions shown above.
>=20
> If it should be, I think SOC_CANAAN should be renamed to SOC_K210 or
> SOC_CANAAN_K210.
>=20