> On Mar 6, 2024, at 01:50, Yangyu Chen <cyy@xxxxxxxxxxxx> wrote: > > The last email was not received in the list due to I didn’t change the mode > to plaintext. Sorry for that. This is a resend email. > >> On Mar 6, 2024, at 01:20, Conor Dooley <conor@xxxxxxxxxx> wrote: >> >> 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. >>>>> >>>>> Signed-off-by: Yangyu Chen <cyy@xxxxxxxxxxxx> >>>>> Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> >>>>> --- >>>>> arch/riscv/Kconfig.socs | 5 ++--- >>>>> 1 file changed, 2 insertions(+), 3 deletions(-) >>>>> >>>>> 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 >>>> >>>> This seems wrong to me. The k210 support does require no-mmu. So why remove >>>> this ? >>> >>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch, >>> nommu_k210_defconfig still works. >> >> 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. >> > > 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. > > 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=y and rebuild, the kernel file will increase to 11M. > 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/d78c601d553dde791057b54252064221f960546e.1586332296.git.zong.li@xxxxxxxxxx/ I know MMU on K210 is not standard as now. Maybe I should care about that. I will fix this for patch v4. >> Maybe you could squash in something like the following? >> >> 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. >> >> config ARCH_CANAAN >> - def_bool SOC_CANAAN >> + bool "Canaan Kendryte SoCs" >> + help >> + This enables support for Canaan Kendryte SoC platform hardware. >> >> 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. >> >> endmenu # "SoC selection" >> >> (Which reminds me, I really need to go and finish sorting out the ARCH_ >> stuff) > > Seems like an idea if we want this consideration. But I don't think we need > this as the opinions shown above. > > If it should be, I think SOC_CANAAN should be renamed to SOC_K210 or > SOC_CANAAN_K210. >
