| Message ID | 20200212103432.660256-3-damien.lemoal@wdc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Kendryte k210 SoC boards support | expand |
Hi, On 2/12/20 5:34 AM, Damien Le Moal wrote: > Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for > a nommu kernel. Since the sparsemem model does not make sense anyway > for the nommu case, do not allow selecting this option to always use > the flatmem model. > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > --- > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 73f029eae0cc..1a3b5a5276be 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE > > config ARCH_SPARSEMEM_ENABLE > def_bool y > + depends on MMU > select SPARSEMEM_VMEMMAP_ENABLE > > config ARCH_SELECT_MEMORY_MODEL > Just for some background, why did you choose NOMMU? Afaik the K210 has an MMU following the RISC-V privileged specification 1.9 --Sean
On 2020/02/15 5:18, Sean Anderson wrote: > Hi, > > On 2/12/20 5:34 AM, Damien Le Moal wrote: >> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for >> a nommu kernel. Since the sparsemem model does not make sense anyway >> for the nommu case, do not allow selecting this option to always use >> the flatmem model. >> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> >> --- >> arch/riscv/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig >> index 73f029eae0cc..1a3b5a5276be 100644 >> --- a/arch/riscv/Kconfig >> +++ b/arch/riscv/Kconfig >> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE >> >> config ARCH_SPARSEMEM_ENABLE >> def_bool y >> + depends on MMU >> select SPARSEMEM_VMEMMAP_ENABLE >> >> config ARCH_SELECT_MEMORY_MODEL >> > > Just for some background, why did you choose NOMMU? Afaik the K210 has > an MMU following the RISC-V privileged specification 1.9 Our early experiments with the k210 with opensbi revealed that the mmu is definitely not a normal one or that it is not functional (e.g. S-mode fault delegation bit setup leads to a hang). So at the time, we started assuming that this is a nommu platform. Since then, others also mentioned that there is in fact an MMU but not following the latest specs (I think Olof mentioned that). But I have not look into this (yet) to try to make it work. Not sure how much effort would be needed on the kernel to support this older specs mmu. In any case, considering the tiny 6+2MB of memory available, direct M-mode Linux boot avoids the bootloader chain and openSBI use, which saves a lot of memory. We could reduce this chain to opensbi with direct payload only, but even then, page alignment will lead to memory loss. And at run-time, nommu saves a lot too with the absence of page tables. Nommu makes sense for this platform. This is the first step to get this platform running Linux. Due to the low memory, it probably isn't a practical use case to use Linux in the first place, but it definitely is a great inexpensive platform for getting started with RISCV. NOMMU allows running Linux without much effort. Going forward, we can also try to get that SoC MMU running. > > --Sean >
On 2/14/20 9:15 PM, Damien Le Moal wrote: > On 2020/02/15 5:18, Sean Anderson wrote: >> Hi, >> >> On 2/12/20 5:34 AM, Damien Le Moal wrote: >>> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for >>> a nommu kernel. Since the sparsemem model does not make sense anyway >>> for the nommu case, do not allow selecting this option to always use >>> the flatmem model. >>> >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> >>> --- >>> arch/riscv/Kconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig >>> index 73f029eae0cc..1a3b5a5276be 100644 >>> --- a/arch/riscv/Kconfig >>> +++ b/arch/riscv/Kconfig >>> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE >>> >>> config ARCH_SPARSEMEM_ENABLE >>> def_bool y >>> + depends on MMU >>> select SPARSEMEM_VMEMMAP_ENABLE >>> >>> config ARCH_SELECT_MEMORY_MODEL >>> >> >> Just for some background, why did you choose NOMMU? Afaik the K210 has >> an MMU following the RISC-V privileged specification 1.9 > > Our early experiments with the k210 with opensbi revealed that the mmu is > definitely not a normal one or that it is not functional (e.g. S-mode fault > delegation bit setup leads to a hang). So at the time, we started assuming > that this is a nommu platform. > > Since then, others also mentioned that there is in fact an MMU but not > following the latest specs (I think Olof mentioned that). But I have not > look into this (yet) to try to make it work. Not sure how much effort would > be needed on the kernel to support this older specs mmu. > > In any case, considering the tiny 6+2MB of memory available, direct M-mode > Linux boot avoids the bootloader chain and openSBI use, which saves a lot > of memory. We could reduce this chain to opensbi with direct payload only, > but even then, page alignment will lead to memory loss. And at run-time, > nommu saves a lot too with the absence of page tables. Nommu makes sense > for this platform. Well, the VM mode bits are in mstatus for this priv spec, so OpenSBI won't work since there is no way to set them. > > This is the first step to get this platform running Linux. Due to the low > memory, it probably isn't a practical use case to use Linux in the first > place, but it definitely is a great inexpensive platform for getting > started with RISCV. NOMMU allows running Linux without much effort. Going > forward, we can also try to get that SoC MMU running. Yeah, that's pretty reasonable. However, I don't think much has changed other than the locations of some of the registers has been changed around. The existing code to set up page table entries should not need major modifications. Alternatively, the base+bound scheme could probably work pretty well with low memory, though we would not be able to re-use any existing code. --Sean
On 2020/02/15 11:26, Sean Anderson wrote: > On 2/14/20 9:15 PM, Damien Le Moal wrote: >> On 2020/02/15 5:18, Sean Anderson wrote: >>> Hi, >>> >>> On 2/12/20 5:34 AM, Damien Le Moal wrote: >>>> Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for >>>> a nommu kernel. Since the sparsemem model does not make sense anyway >>>> for the nommu case, do not allow selecting this option to always use >>>> the flatmem model. >>>> >>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> >>>> --- >>>> arch/riscv/Kconfig | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig >>>> index 73f029eae0cc..1a3b5a5276be 100644 >>>> --- a/arch/riscv/Kconfig >>>> +++ b/arch/riscv/Kconfig >>>> @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE >>>> >>>> config ARCH_SPARSEMEM_ENABLE >>>> def_bool y >>>> + depends on MMU >>>> select SPARSEMEM_VMEMMAP_ENABLE >>>> >>>> config ARCH_SELECT_MEMORY_MODEL >>>> >>> >>> Just for some background, why did you choose NOMMU? Afaik the K210 has >>> an MMU following the RISC-V privileged specification 1.9 >> >> Our early experiments with the k210 with opensbi revealed that the mmu is >> definitely not a normal one or that it is not functional (e.g. S-mode fault >> delegation bit setup leads to a hang). So at the time, we started assuming >> that this is a nommu platform. >> >> Since then, others also mentioned that there is in fact an MMU but not >> following the latest specs (I think Olof mentioned that). But I have not >> look into this (yet) to try to make it work. Not sure how much effort would >> be needed on the kernel to support this older specs mmu. >> >> In any case, considering the tiny 6+2MB of memory available, direct M-mode >> Linux boot avoids the bootloader chain and openSBI use, which saves a lot >> of memory. We could reduce this chain to opensbi with direct payload only, >> but even then, page alignment will lead to memory loss. And at run-time, >> nommu saves a lot too with the absence of page tables. Nommu makes sense >> for this platform. > > Well, the VM mode bits are in mstatus for this priv spec, so OpenSBI > won't work since there is no way to set them. Interesting. At FOSDEM, we discussed with Palmer the work that would be needed to disentangle NOMMU and M-MODE boot, which for now are rather synonymous, but shouldn't. I guess this platform would still require M-MODE boot, but not necessarily NOMMU. >> This is the first step to get this platform running Linux. Due to the low >> memory, it probably isn't a practical use case to use Linux in the first >> place, but it definitely is a great inexpensive platform for getting >> started with RISCV. NOMMU allows running Linux without much effort. Going >> forward, we can also try to get that SoC MMU running. > > Yeah, that's pretty reasonable. However, I don't think much has changed > other than the locations of some of the registers has been changed > around. The existing code to set up page table entries should not need > major modifications. OK. Sounds easy enough. But I think cleanup work to dissociate M-mode boot and NOMMU will be needed first. After that, trying to enable the MMU should be easier. > > Alternatively, the base+bound scheme could probably work pretty well > with low memory, though we would not be able to re-use any existing > code. > > --Sean >
On Wed, Feb 12, 2020 at 4:04 PM Damien Le Moal <damien.lemoal@wdc.com> wrote: > > Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for > a nommu kernel. Since the sparsemem model does not make sense anyway > for the nommu case, do not allow selecting this option to always use > the flatmem model. > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> LGTM. Reviewed-by: Anup Patel <anup@brainfault.org> Regards, Anup > --- > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 73f029eae0cc..1a3b5a5276be 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE > > config ARCH_SPARSEMEM_ENABLE > def_bool y > + depends on MMU > select SPARSEMEM_VMEMMAP_ENABLE > > config ARCH_SELECT_MEMORY_MODEL > -- > 2.24.1 > >
On Wed, 12 Feb 2020 02:34:24 PST (-0800), Damien Le Moal wrote: > Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for > a nommu kernel. Since the sparsemem model does not make sense anyway > for the nommu case, do not allow selecting this option to always use > the flatmem model. > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > --- > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 73f029eae0cc..1a3b5a5276be 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE > > config ARCH_SPARSEMEM_ENABLE > def_bool y > + depends on MMU > select SPARSEMEM_VMEMMAP_ENABLE > > config ARCH_SELECT_MEMORY_MODEL Oh, this should go in fixes too. Thanks! Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 73f029eae0cc..1a3b5a5276be 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -121,6 +121,7 @@ config ARCH_FLATMEM_ENABLE config ARCH_SPARSEMEM_ENABLE def_bool y + depends on MMU select SPARSEMEM_VMEMMAP_ENABLE config ARCH_SELECT_MEMORY_MODEL
Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for a nommu kernel. Since the sparsemem model does not make sense anyway for the nommu case, do not allow selecting this option to always use the flatmem model. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+)