Deprecation of NOMMU support for riscv was discussed during LPC 2023
[1]. Reasons for this involves lack of users as well as maintenance
efforts to support this mode. psABI FDPIC specification also never
made it upstream and last public messages of this development seems to
date back from 2020 [2]. Plan the deprecation to be done in 2 years from
now. Mark the Kconfig option as deprecated by adding a new dummy option
which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
select another one directly with a "select" in case of such CONFIG=n.
Additionally, display a pr_err() message at boot time in case of NOMMU
build to warn about upcoming deprecation.
Link: https://lpc.events/event/17/contributions/1478/ [1]
Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/Kconfig | 8 ++++++++
arch/riscv/kernel/setup.c | 4 ++++
2 files changed, 12 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index bffbd869a068..8da58c102d3f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
# set if we run in machine mode, cleared if we run in supervisor mode
config RISCV_M_MODE
bool
+ select NOMMU
default !MMU
# set if we are running in S-mode and can use SBI calls
@@ -236,6 +237,13 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
+config NOMMU
+ depends on !MMU
+ bool "NOMMU kernel (DEPRECATED)"
+ help
+ NOMMU kernel is deprecated and is scheduled for removal by
+ the beginning of 2027.
+
config PAGE_OFFSET
hex
default 0xC0000000 if 32BIT && MMU
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 4f73c0ae44b2..8799816ef0a6 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
riscv_set_dma_cache_alignment();
riscv_user_isa_enable();
+
+#if !defined(CONFIG_MMU)
+ pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
+#endif
}
bool arch_cpu_is_hotpluggable(int cpu)
--
2.43.0
On 2024/02/26 6:06, Clément Léger wrote:
> Deprecation of NOMMU support for riscv was discussed during LPC 2023
> [1]. Reasons for this involves lack of users as well as maintenance
> efforts to support this mode. psABI FDPIC specification also never
> made it upstream and last public messages of this development seems to
> date back from 2020 [2]. Plan the deprecation to be done in 2 years from
> now. Mark the Kconfig option as deprecated by adding a new dummy option
> which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
> is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
> select another one directly with a "select" in case of such CONFIG=n.
> Additionally, display a pr_err() message at boot time in case of NOMMU
> build to warn about upcoming deprecation.
>
> Link: https://lpc.events/event/17/contributions/1478/ [1]
> Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
> Signed-off-by: Clément Léger <[email protected]>
>
> ---
> arch/riscv/Kconfig | 8 ++++++++
> arch/riscv/kernel/setup.c | 4 ++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index bffbd869a068..8da58c102d3f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
> # set if we run in machine mode, cleared if we run in supervisor mode
> config RISCV_M_MODE
> bool
> + select NOMMU
> default !MMU
>
> # set if we are running in S-mode and can use SBI calls
> @@ -236,6 +237,13 @@ config MMU
> Select if you want MMU-based virtualised addressing space
> support by paged memory management. If unsure, say 'Y'.
>
> +config NOMMU
> + depends on !MMU
> + bool "NOMMU kernel (DEPRECATED)"
> + help
> + NOMMU kernel is deprecated and is scheduled for removal by
> + the beginning of 2027.
2 years from now is 2026...
> +
> config PAGE_OFFSET
> hex
> default 0xC0000000 if 32BIT && MMU
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 4f73c0ae44b2..8799816ef0a6 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
> riscv_set_dma_cache_alignment();
>
> riscv_user_isa_enable();
> +
> +#if !defined(CONFIG_MMU)
if (!IS_ENABLED(CONFIG_MMU))
would be more elegant here...
> + pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
Why pr_err() ? pr_warn() seems more appropriate.
> +#endif
> }
>
> bool arch_cpu_is_hotpluggable(int cpu)
--
Damien Le Moal
Western Digital Research
On 2024/02/26 6:59, Clément Léger wrote:
>
>
> On 26/02/2024 15:57, Damien Le Moal wrote:
>> On 2024/02/26 6:06, Clément Léger wrote:
>>> Deprecation of NOMMU support for riscv was discussed during LPC 2023
>>> [1]. Reasons for this involves lack of users as well as maintenance
>>> efforts to support this mode. psABI FDPIC specification also never
>>> made it upstream and last public messages of this development seems to
>>> date back from 2020 [2]. Plan the deprecation to be done in 2 years from
>>> now. Mark the Kconfig option as deprecated by adding a new dummy option
>>> which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
>>> is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
>>> select another one directly with a "select" in case of such CONFIG=n.
>>> Additionally, display a pr_err() message at boot time in case of NOMMU
>>> build to warn about upcoming deprecation.
>>>
>>> Link: https://lpc.events/event/17/contributions/1478/ [1]
>>> Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
>>> Signed-off-by: Clément Léger <[email protected]>
>>>
>>> ---
>>> arch/riscv/Kconfig | 8 ++++++++
>>> arch/riscv/kernel/setup.c | 4 ++++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>> index bffbd869a068..8da58c102d3f 100644
>>> --- a/arch/riscv/Kconfig
>>> +++ b/arch/riscv/Kconfig
>>> @@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
>>> # set if we run in machine mode, cleared if we run in supervisor mode
>>> config RISCV_M_MODE
>>> bool
>>> + select NOMMU
>>> default !MMU
>>>
>>> # set if we are running in S-mode and can use SBI calls
>>> @@ -236,6 +237,13 @@ config MMU
>>> Select if you want MMU-based virtualised addressing space
>>> support by paged memory management. If unsure, say 'Y'.
>>>
>>> +config NOMMU
>>> + depends on !MMU
>>> + bool "NOMMU kernel (DEPRECATED)"
>>> + help
>>> + NOMMU kernel is deprecated and is scheduled for removal by
>>> + the beginning of 2027.
>>
>> 2 years from now is 2026...
>
> Guess I'm a bit tired -_-'
Off-by-1 bug. It happens :)
>
>>
>>> +
>>> config PAGE_OFFSET
>>> hex
>>> default 0xC0000000 if 32BIT && MMU
>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>>> index 4f73c0ae44b2..8799816ef0a6 100644
>>> --- a/arch/riscv/kernel/setup.c
>>> +++ b/arch/riscv/kernel/setup.c
>>> @@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
>>> riscv_set_dma_cache_alignment();
>>>
>>> riscv_user_isa_enable();
>>> +
>>> +#if !defined(CONFIG_MMU)
>>
>> if (!IS_ENABLED(CONFIG_MMU))
>>
>> would be more elegant here...
>
> Sure.
>
>>
>>> + pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
>>
>> Why pr_err() ? pr_warn() seems more appropriate.
>
> Agreed.
>
> Thanks,
>
> Clément
>
>>
>>> +#endif
>>> }
>>>
>>> bool arch_cpu_is_hotpluggable(int cpu)
>>
--
Damien Le Moal
Western Digital Research
On 26/02/2024 16:14, Samuel Holland wrote:
> On 2024-02-26 8:06 AM, Clément Léger wrote:
>> Deprecation of NOMMU support for riscv was discussed during LPC 2023
>> [1]. Reasons for this involves lack of users as well as maintenance
>> efforts to support this mode. psABI FDPIC specification also never
>> made it upstream and last public messages of this development seems to
>> date back from 2020 [2]. Plan the deprecation to be done in 2 years from
>
> What are the criteria for delaying/canceling the removal? NOMMU support doesn't
> rot nearly as fast as XIP; static PIE ELF works and is well specified; and as
> mentioned at LPC, there are some users, even if "just for fun".
Hi Samuel,
I was actually developing some feature that encountered NOMMU build
failures and I was reminded that NOMMU was discussed to be deprecated
during last LPC. I guess I could also mark XIP as deprecated. The
rationale behind delaying is to let some users to manifest themselves
before a full removal. But this can still be discussed of course, this
patch was also meant to trigger such feedback.
>
>> now. Mark the Kconfig option as deprecated by adding a new dummy option
>> which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
>> is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
>> select another one directly with a "select" in case of such CONFIG=n.
>> Additionally, display a pr_err() message at boot time in case of NOMMU
>> build to warn about upcoming deprecation.
>>
>> Link: https://lpc.events/event/17/contributions/1478/ [1]
>> Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
>> Signed-off-by: Clément Léger <[email protected]>
>>
>> ---
>> arch/riscv/Kconfig | 8 ++++++++
>> arch/riscv/kernel/setup.c | 4 ++++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index bffbd869a068..8da58c102d3f 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> # set if we run in machine mode, cleared if we run in supervisor mode
>> config RISCV_M_MODE
>> bool
>> + select NOMMU
>> default !MMU
>>
>> # set if we are running in S-mode and can use SBI calls
>> @@ -236,6 +237,13 @@ config MMU
>> Select if you want MMU-based virtualised addressing space
>> support by paged memory management. If unsure, say 'Y'.
>>
>> +config NOMMU
>> + depends on !MMU
>> + bool "NOMMU kernel (DEPRECATED)"
>> + help
>> + NOMMU kernel is deprecated and is scheduled for removal by
>> + the beginning of 2027.
>> +
>
> The idiomatic way to display this kind of warning is a comment directive:
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d4e890fb5b5a..b736440ce0f7 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -248,6 +248,9 @@ config MMU
> Select if you want MMU-based virtualised addressing space
> support by paged memory management. If unsure, say 'Y'.
>
> +comment "NOMMU support is deprecated (scheduled for removal in 2027)"
> + depends on !MMU
> +
Thanks, I was not able to find any example of such usage.
Clément
> config PAGE_OFFSET
> hex
> default 0xC0000000 if 32BIT && MMU
>
> Regards,
> Samuel
>
>> config PAGE_OFFSET
>> hex
>> default 0xC0000000 if 32BIT && MMU
>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>> index 4f73c0ae44b2..8799816ef0a6 100644
>> --- a/arch/riscv/kernel/setup.c
>> +++ b/arch/riscv/kernel/setup.c
>> @@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
>> riscv_set_dma_cache_alignment();
>>
>> riscv_user_isa_enable();
>> +
>> +#if !defined(CONFIG_MMU)
>> + pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
>> +#endif
>> }
>>
>> bool arch_cpu_is_hotpluggable(int cpu)
>
On 2024-02-26 8:06 AM, Clément Léger wrote:
> Deprecation of NOMMU support for riscv was discussed during LPC 2023
> [1]. Reasons for this involves lack of users as well as maintenance
> efforts to support this mode. psABI FDPIC specification also never
> made it upstream and last public messages of this development seems to
> date back from 2020 [2]. Plan the deprecation to be done in 2 years from
What are the criteria for delaying/canceling the removal? NOMMU support doesn't
rot nearly as fast as XIP; static PIE ELF works and is well specified; and as
mentioned at LPC, there are some users, even if "just for fun".
> now. Mark the Kconfig option as deprecated by adding a new dummy option
> which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
> is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
> select another one directly with a "select" in case of such CONFIG=n.
> Additionally, display a pr_err() message at boot time in case of NOMMU
> build to warn about upcoming deprecation.
>
> Link: https://lpc.events/event/17/contributions/1478/ [1]
> Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
> Signed-off-by: Clément Léger <[email protected]>
>
> ---
> arch/riscv/Kconfig | 8 ++++++++
> arch/riscv/kernel/setup.c | 4 ++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index bffbd869a068..8da58c102d3f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
> # set if we run in machine mode, cleared if we run in supervisor mode
> config RISCV_M_MODE
> bool
> + select NOMMU
> default !MMU
>
> # set if we are running in S-mode and can use SBI calls
> @@ -236,6 +237,13 @@ config MMU
> Select if you want MMU-based virtualised addressing space
> support by paged memory management. If unsure, say 'Y'.
>
> +config NOMMU
> + depends on !MMU
> + bool "NOMMU kernel (DEPRECATED)"
> + help
> + NOMMU kernel is deprecated and is scheduled for removal by
> + the beginning of 2027.
> +
The idiomatic way to display this kind of warning is a comment directive:
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d4e890fb5b5a..b736440ce0f7 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -248,6 +248,9 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
+comment "NOMMU support is deprecated (scheduled for removal in 2027)"
+ depends on !MMU
+
config PAGE_OFFSET
hex
default 0xC0000000 if 32BIT && MMU
Regards,
Samuel
> config PAGE_OFFSET
> hex
> default 0xC0000000 if 32BIT && MMU
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 4f73c0ae44b2..8799816ef0a6 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
> riscv_set_dma_cache_alignment();
>
> riscv_user_isa_enable();
> +
> +#if !defined(CONFIG_MMU)
> + pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
> +#endif
> }
>
> bool arch_cpu_is_hotpluggable(int cpu)
On 26/02/2024 15:57, Damien Le Moal wrote:
> On 2024/02/26 6:06, Clément Léger wrote:
>> Deprecation of NOMMU support for riscv was discussed during LPC 2023
>> [1]. Reasons for this involves lack of users as well as maintenance
>> efforts to support this mode. psABI FDPIC specification also never
>> made it upstream and last public messages of this development seems to
>> date back from 2020 [2]. Plan the deprecation to be done in 2 years from
>> now. Mark the Kconfig option as deprecated by adding a new dummy option
>> which explicitly displays the deprecation in case of CONFIG_MMU=n. This option
>> is selected indirectly by CONFIG_RISCV_M_MODE since an option can not
>> select another one directly with a "select" in case of such CONFIG=n.
>> Additionally, display a pr_err() message at boot time in case of NOMMU
>> build to warn about upcoming deprecation.
>>
>> Link: https://lpc.events/event/17/contributions/1478/ [1]
>> Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/WYRRylTwAAAJ [2]
>> Signed-off-by: Clément Léger <[email protected]>
>>
>> ---
>> arch/riscv/Kconfig | 8 ++++++++
>> arch/riscv/kernel/setup.c | 4 ++++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index bffbd869a068..8da58c102d3f 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -221,6 +221,7 @@ config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> # set if we run in machine mode, cleared if we run in supervisor mode
>> config RISCV_M_MODE
>> bool
>> + select NOMMU
>> default !MMU
>>
>> # set if we are running in S-mode and can use SBI calls
>> @@ -236,6 +237,13 @@ config MMU
>> Select if you want MMU-based virtualised addressing space
>> support by paged memory management. If unsure, say 'Y'.
>>
>> +config NOMMU
>> + depends on !MMU
>> + bool "NOMMU kernel (DEPRECATED)"
>> + help
>> + NOMMU kernel is deprecated and is scheduled for removal by
>> + the beginning of 2027.
>
> 2 years from now is 2026...
Guess I'm a bit tired -_-'
>
>> +
>> config PAGE_OFFSET
>> hex
>> default 0xC0000000 if 32BIT && MMU
>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>> index 4f73c0ae44b2..8799816ef0a6 100644
>> --- a/arch/riscv/kernel/setup.c
>> +++ b/arch/riscv/kernel/setup.c
>> @@ -295,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
>> riscv_set_dma_cache_alignment();
>>
>> riscv_user_isa_enable();
>> +
>> +#if !defined(CONFIG_MMU)
>
> if (!IS_ENABLED(CONFIG_MMU))
>
> would be more elegant here...
Sure.
>
>> + pr_err("RISC-V NOMMU support is deprecated and scheduled for removal by the beginning of 2027\n");
>
> Why pr_err() ? pr_warn() seems more appropriate.
Agreed.
Thanks,
Clément
>
>> +#endif
>> }
>>
>> bool arch_cpu_is_hotpluggable(int cpu)
>
On Mon, Feb 26, 2024 at 04:25:24PM +0100, Cl?ment L?ger wrote:
> I guess I could also mark XIP as deprecated.
I'm not so sure, people recently added XIP support to QEMU (and sent
kernel fixes in December). XIP is also not nearly as much of a problem
to support, there's far less that it does differently, the main barrier
was the inability to test it which is no longer the case.
That said, XIP is gonna kill itself off I feel as it does not support
runtime patching and therefore is extremely limited on extensions, given
we use alternatives for all of that (although I suppose if someone has a
usecase they could make nasty macros worse and implement a compiletime
switch in the alternatives too).
Cheers,
Conor.
WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
for Linux, as well as some limited systems.
I get new copies of the kernel when there are releases and test them
frequently to make sure everything is still working as expected.
For us we just don't care about XIP. I mean if someone did push it
through to fruition, I'd also test and use it, but I urge you please
do not deprecate this. While it's sometimes needed a bit of a
creative build to get everything working, I've never needed to patch
anything in the kernel beyond patching in a custom console for serial
output.
I am happy to discuss the possibility of me and or one of the other
RISC-V soft (FPGA) core people stepping up to try to be more active,
but so far we've just been very well serviced by the current NOMMU
Linux setup.
Charles
On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
>
> On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > I guess I could also mark XIP as deprecated.
>
> I'm not so sure, people recently added XIP support to QEMU (and sent
> kernel fixes in December). XIP is also not nearly as much of a problem
> to support, there's far less that it does differently, the main barrier
> was the inability to test it which is no longer the case.
> That said, XIP is gonna kill itself off I feel as it does not support
> runtime patching and therefore is extremely limited on extensions, given
> we use alternatives for all of that (although I suppose if someone has a
> usecase they could make nasty macros worse and implement a compiletime
> switch in the alternatives too).
>
> Cheers,
> Conor.
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Mon, Feb 26, 2024 at 11:00:41AM -0800, Charles Lohr wrote:
> WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> for Linux, as well as some limited systems.
>
> I get new copies of the kernel when there are releases and test them
> frequently to make sure everything is still working as expected.
That is great - it is good to know that people are actively testing.
I was aware that a lot of the soft core folks did run nommu kernels (and
I know some do use XIP also) but everything I ever saw was running on
old kernels (5.x).
> On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> >
> > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > I guess I could also mark XIP as deprecated.
> >
> > I'm not so sure, people recently added XIP support to QEMU (and sent
> > kernel fixes in December). XIP is also not nearly as much of a problem
> > to support, there's far less that it does differently, the main barrier
> > was the inability to test it which is no longer the case.
> > That said, XIP is gonna kill itself off I feel as it does not support
> > runtime patching and therefore is extremely limited on extensions, given
> > we use alternatives for all of that (although I suppose if someone has a
> > usecase they could make nasty macros worse and implement a compiletime
> > switch in the alternatives too).
> For us we just don't care about XIP. I mean if someone did push it
> through to fruition, I'd also test and use it, but I urge you please
> do not deprecate this.
XIP does work. What I was talking about here was supporting something
"fancier" than rv{32,64}imafdc.
> While it's sometimes needed a bit of a
> creative build to get everything working, I've never needed to patch
> anything in the kernel beyond patching in a custom console for serial
> output.
>
> I am happy to discuss the possibility of me and or one of the other
> RISC-V soft (FPGA) core people stepping up to try to be more active,
> but so far we've just been very well serviced by the current NOMMU
> Linux setup.
Most of the issues aren't with nommu actually working, it is the extra
effort in development as it has to be accounted for. I would estimate
that 2/3 of the build issues I report on this list are nommu. The
best thing that you can do to ensure support for things you use is:
a) scream when someone wants to remove it
b) actively let people know you're using it
Seems like you're doing a) but maybe getting someone that provides
Tested-bys whenever you test the releases would be good.
Cheers,
Conor.
On 26/02/2024 20:00, Charles Lohr wrote:
> WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> for Linux, as well as some limited systems.
>
> I get new copies of the kernel when there are releases and test them
> frequently to make sure everything is still working as expected.
>
> For us we just don't care about XIP. I mean if someone did push it
> through to fruition, I'd also test and use it, but I urge you please
> do not deprecate this. While it's sometimes needed a bit of a
> creative build to get everything working, I've never needed to patch
> anything in the kernel beyond patching in a custom console for serial
> output.
>
Hey Charles,
No worries, we actually did not expected NOMMU to have *so many* users.
I guess deprecating stuff is a good way to have immediate feedback ;).
Having FDPIC psABI to be merged upstream could also probably be a
positive point toward a better NOMMU support.
> I am happy to discuss the possibility of me and or one of the other
> RISC-V soft (FPGA) core people stepping up to try to be more active,
> but so far we've just been very well serviced by the current NOMMU
> Linux setup.
It could probably be nice to have some feedback/Tested-by: from NOMMU
users for new releases then.
Thanks,
Clément
>
> Charles
>
>
> On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
>>
>> On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
>>> I guess I could also mark XIP as deprecated.
>>
>> I'm not so sure, people recently added XIP support to QEMU (and sent
>> kernel fixes in December). XIP is also not nearly as much of a problem
>> to support, there's far less that it does differently, the main barrier
>> was the inability to test it which is no longer the case.
>> That said, XIP is gonna kill itself off I feel as it does not support
>> runtime patching and therefore is extremely limited on extensions, given
>> we use alternatives for all of that (although I suppose if someone has a
>> usecase they could make nasty macros worse and implement a compiletime
>> switch in the alternatives too).
>>
>> Cheers,
>> Conor.
>>
>> _______________________________________________
>> linux-riscv mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
>
>
> On 26/02/2024 20:00, Charles Lohr wrote:
>> WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
>> and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
>> for Linux, as well as some limited systems.
OK.
I just build test this stuff, as I don't really have a use for it
personally. I figured if nobody's reporting bugs then probably it's
broken and nobody's noticed because nobody's using it.
>> I get new copies of the kernel when there are releases and test them
>> frequently to make sure everything is still working as expected.
I'd actually expected it to be broken, but I guess we managed to avoid
screwing things up ;)
>> For us we just don't care about XIP. I mean if someone did push it
>> through to fruition, I'd also test and use it, but I urge you please
>> do not deprecate this. While it's sometimes needed a bit of a
>> creative build to get everything working, I've never needed to patch
>> anything in the kernel beyond patching in a custom console for serial
>> output.
>>
>
> Hey Charles,
>
> No worries, we actually did not expected NOMMU to have *so many* users.
> I guess deprecating stuff is a good way to have immediate feedback ;).
> Having FDPIC psABI to be merged upstream could also probably be a
> positive point toward a better NOMMU support.
Ya, that's probably the right way to do it. Touching anything in the
psABI is pretty miserable, though, so I don't really want to force
people to do it...
>> I am happy to discuss the possibility of me and or one of the other
>> RISC-V soft (FPGA) core people stepping up to try to be more active,
>> but so far we've just been very well serviced by the current NOMMU
>> Linux setup.
>
> It could probably be nice to have some feedback/Tested-by: from NOMMU
> users for new releases then.
Having more upstream interaction from users is always appreciated,
that's the best way to prove people are using the code. If you guys
have the time it'd be great to get this into some sort of CI, ideally
running on some real platform.
> Thanks,
>
> Clément
>
>>
>> Charles
>>
>>
>> On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
>>>
>>> On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
>>>> I guess I could also mark XIP as deprecated.
>>>
>>> I'm not so sure, people recently added XIP support to QEMU (and sent
>>> kernel fixes in December). XIP is also not nearly as much of a problem
>>> to support, there's far less that it does differently, the main barrier
>>> was the inability to test it which is no longer the case.
>>> That said, XIP is gonna kill itself off I feel as it does not support
>>> runtime patching and therefore is extremely limited on extensions, given
>>> we use alternatives for all of that (although I suppose if someone has a
>>> usecase they could make nasty macros worse and implement a compiletime
>>> switch in the alternatives too).
>>>
>>> Cheers,
>>> Conor.
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> >
> >
> > On 26/02/2024 20:00, Charles Lohr wrote:
> > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > for Linux, as well as some limited systems.
>
> OK.
>
> I just build test this stuff, as I don't really have a use for it
> personally. I figured if nobody's reporting bugs then probably it's broken
> and nobody's noticed because nobody's using it.
>
> > > I get new copies of the kernel when there are releases and test them
> > > frequently to make sure everything is still working as expected.
>
> I'd actually expected it to be broken, but I guess we managed to avoid
> screwing things up ;)
>
> > > For us we just don't care about XIP. I mean if someone did push it
I don't care XIP either, and IMHO the XIP's maintenance effort is much
bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
code readability will be much better.
Or sending out a similar XIP deprecation patch to see whether there's
any complain ? ;)
> > > through to fruition, I'd also test and use it, but I urge you please
> > > do not deprecate this. While it's sometimes needed a bit of a
+1 for urge the upstream please do not deprecate NOMMU.
Besides the soft(FPGA) core mentioned by Charles, here is another real
usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
core)w/o MMU. The vendor sdk runs freertos on the small core, but it
doesn't prevent users to run other OS such as threadx, zephyr or nommu
linux on the small core. In fact, I sucessfully brought up nommu linux
on the small core. I didn't just send out the patches in time during this
dev window duo to my personal career reason(I spent the time on hunting
for a new job)
I plan to send out NOMMU related patches once 6.9-rc1 is out.
> > > creative build to get everything working, I've never needed to patch
> > > anything in the kernel beyond patching in a custom console for serial
> > > output.
> > >
> >
> > Hey Charles,
> >
> > No worries, we actually did not expected NOMMU to have *so many* users.
> > I guess deprecating stuff is a good way to have immediate feedback ;).
> > Having FDPIC psABI to be merged upstream could also probably be a
> > positive point toward a better NOMMU support.
>
> Ya, that's probably the right way to do it. Touching anything in the psABI
> is pretty miserable, though, so I don't really want to force people to do
> it...
>
> > > I am happy to discuss the possibility of me and or one of the other
> > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > but so far we've just been very well serviced by the current NOMMU
> > > Linux setup.
> >
> > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > users for new releases then.
>
> Having more upstream interaction from users is always appreciated, that's
> the best way to prove people are using the code. If you guys have the time
> it'd be great to get this into some sort of CI, ideally running on some real
> platform.
As above, I'd also like to step up on the NOMMU stuff, at least test
nommu on milkv duo's small core. And can be seen from my git commit
histotry, I was active, and I belive I will still be active on riscv linux
kernel development.
>
> > Thanks,
> >
> > Clément
> >
> > >
> > > Charles
> > >
> > >
> > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > >
> > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > I guess I could also mark XIP as deprecated.
> > > >
> > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > to support, there's far less that it does differently, the main barrier
> > > > was the inability to test it which is no longer the case.
> > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > runtime patching and therefore is extremely limited on extensions, given
> > > > we use alternatives for all of that (although I suppose if someone has a
> > > > usecase they could make nasty macros worse and implement a compiletime
> > > > switch in the alternatives too).
> > > >
> > > > Cheers,
> > > > Conor.
> > > >
> > > > _______________________________________________
> > > > linux-riscv mailing list
> > > > [email protected]
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> > >
> > >
> > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > for Linux, as well as some limited systems.
> >
> > OK.
> >
> > I just build test this stuff, as I don't really have a use for it
> > personally. I figured if nobody's reporting bugs then probably it's broken
> > and nobody's noticed because nobody's using it.
> >
> > > > I get new copies of the kernel when there are releases and test them
> > > > frequently to make sure everything is still working as expected.
> >
> > I'd actually expected it to be broken, but I guess we managed to avoid
> > screwing things up ;)
> >
> > > > For us we just don't care about XIP. I mean if someone did push it
>
> I don't care XIP either, and IMHO the XIP's maintenance effort is much
> bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> code readability will be much better.
>
> Or sending out a similar XIP deprecation patch to see whether there's
> any complain ? ;)
>
> > > > through to fruition, I'd also test and use it, but I urge you please
> > > > do not deprecate this. While it's sometimes needed a bit of a
>
> +1 for urge the upstream please do not deprecate NOMMU.
>
> Besides the soft(FPGA) core mentioned by Charles, here is another real
And I'd like to write more about soft core: riscv is a free and open
ISA, this make it really good for education, for simple riscv
implementation or emulator. Once riscv IMA is implemented(even if MMU,
cache, TLB stuff don't exist), it's not far away from making linux
running on the FPGA or emulator. If the gain is larger than the maintenance
effort, I'd like to urge keeping the NOMMU support.
Thanks a lot
> usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> doesn't prevent users to run other OS such as threadx, zephyr or nommu
> linux on the small core. In fact, I sucessfully brought up nommu linux
> on the small core. I didn't just send out the patches in time during this
> dev window duo to my personal career reason(I spent the time on hunting
> for a new job)
>
> I plan to send out NOMMU related patches once 6.9-rc1 is out.
>
> > > > creative build to get everything working, I've never needed to patch
> > > > anything in the kernel beyond patching in a custom console for serial
> > > > output.
> > > >
> > >
> > > Hey Charles,
> > >
> > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > Having FDPIC psABI to be merged upstream could also probably be a
> > > positive point toward a better NOMMU support.
> >
> > Ya, that's probably the right way to do it. Touching anything in the psABI
> > is pretty miserable, though, so I don't really want to force people to do
> > it...
> >
> > > > I am happy to discuss the possibility of me and or one of the other
> > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > but so far we've just been very well serviced by the current NOMMU
> > > > Linux setup.
> > >
> > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > users for new releases then.
> >
> > Having more upstream interaction from users is always appreciated, that's
> > the best way to prove people are using the code. If you guys have the time
> > it'd be great to get this into some sort of CI, ideally running on some real
> > platform.
>
> As above, I'd also like to step up on the NOMMU stuff, at least test
> nommu on milkv duo's small core. And can be seen from my git commit
> histotry, I was active, and I belive I will still be active on riscv linux
> kernel development.
>
> >
> > > Thanks,
> > >
> > > Clément
> > >
> > > >
> > > > Charles
> > > >
> > > >
> > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > > >
> > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > I guess I could also mark XIP as deprecated.
> > > > >
> > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > to support, there's far less that it does differently, the main barrier
> > > > > was the inability to test it which is no longer the case.
> > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > switch in the alternatives too).
> > > > >
> > > > > Cheers,
> > > > > Conor.
> > > > >
> > > > > _______________________________________________
> > > > > linux-riscv mailing list
> > > > > [email protected]
> > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> > _______________________________________________
> > linux-riscv mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Mar 14, 2024 at 09:02:43PM +0800, Jisheng Zhang wrote:
> On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> > On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > > On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> > > >
> > > >
> > > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > > for Linux, as well as some limited systems.
> > >
> > > OK.
> > >
> > > I just build test this stuff, as I don't really have a use for it
> > > personally. I figured if nobody's reporting bugs then probably it's broken
> > > and nobody's noticed because nobody's using it.
> > >
> > > > > I get new copies of the kernel when there are releases and test them
> > > > > frequently to make sure everything is still working as expected.
> > >
> > > I'd actually expected it to be broken, but I guess we managed to avoid
> > > screwing things up ;)
> > >
> > > > > For us we just don't care about XIP. I mean if someone did push it
> >
> > I don't care XIP either, and IMHO the XIP's maintenance effort is much
> > bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> > macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> > code readability will be much better.
> >
> > Or sending out a similar XIP deprecation patch to see whether there's
> > any complain ? ;)
> >
> > > > > through to fruition, I'd also test and use it, but I urge you please
> > > > > do not deprecate this. While it's sometimes needed a bit of a
> >
> > +1 for urge the upstream please do not deprecate NOMMU.
> >
> > Besides the soft(FPGA) core mentioned by Charles, here is another real
>
> And I'd like to write more about soft core: riscv is a free and open
> ISA, this make it really good for education, for simple riscv
> implementation or emulator. Once riscv IMA is implemented(even if MMU,
> cache, TLB stuff don't exist), it's not far away from making linux
> running on the FPGA or emulator. If the gain is larger than the maintenance
> effort, I'd like to urge keeping the NOMMU support.
>
> Thanks a lot
>
> > usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> > contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> > core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> > doesn't prevent users to run other OS such as threadx, zephyr or nommu
> > linux on the small core. In fact, I sucessfully brought up nommu linux
> > on the small core. I didn't just send out the patches in time during this
> > dev window duo to my personal career reason(I spent the time on hunting
> > for a new job)
> >
> > I plan to send out NOMMU related patches once 6.9-rc1 is out.
As is promised, the NOMMU improvement patches are sent out
https://lore.kernel.org/linux-riscv/[email protected]/T/#t
Thanks
> >
> > > > > creative build to get everything working, I've never needed to patch
> > > > > anything in the kernel beyond patching in a custom console for serial
> > > > > output.
> > > > >
> > > >
> > > > Hey Charles,
> > > >
> > > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > > Having FDPIC psABI to be merged upstream could also probably be a
> > > > positive point toward a better NOMMU support.
> > >
> > > Ya, that's probably the right way to do it. Touching anything in the psABI
> > > is pretty miserable, though, so I don't really want to force people to do
> > > it...
> > >
> > > > > I am happy to discuss the possibility of me and or one of the other
> > > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > > but so far we've just been very well serviced by the current NOMMU
> > > > > Linux setup.
> > > >
> > > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > > users for new releases then.
> > >
> > > Having more upstream interaction from users is always appreciated, that's
> > > the best way to prove people are using the code. If you guys have the time
> > > it'd be great to get this into some sort of CI, ideally running on some real
> > > platform.
> >
> > As above, I'd also like to step up on the NOMMU stuff, at least test
> > nommu on milkv duo's small core. And can be seen from my git commit
> > histotry, I was active, and I belive I will still be active on riscv linux
> > kernel development.
> >
> > >
> > > > Thanks,
> > > >
> > > > Clément
> > > >
> > > > >
> > > > > Charles
> > > > >
> > > > >
> > > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > > > >
> > > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > > I guess I could also mark XIP as deprecated.
> > > > > >
> > > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > > to support, there's far less that it does differently, the main barrier
> > > > > > was the inability to test it which is no longer the case.
> > > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > > switch in the alternatives too).
> > > > > >
> > > > > > Cheers,
> > > > > > Conor.
> > > > > >
> > > > > > _______________________________________________
> > > > > > linux-riscv mailing list
> > > > > > [email protected]
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > [email protected]
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
Jisheng, are you using musl or uclibc? I've been having difficulty
getting new versions of each working with the newer kernels with
system calls not lining up.
Also, is there a better place to ask questions about the more
user-spacy stuff? That's really where I've been struggling to
maintain things, keeping buildroot working when targeting RV32 NOMMU.
Thankfully a lot of the stickiest problems have all been upstreamed.
Charles
On Mon, Mar 25, 2024 at 10:12 AM Jisheng Zhang <[email protected]> wrote:
>
> On Thu, Mar 14, 2024 at 09:02:43PM +0800, Jisheng Zhang wrote:
> > On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> > > On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > > > On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> > > > >
> > > > >
> > > > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > > > for Linux, as well as some limited systems.
> > > >
> > > > OK.
> > > >
> > > > I just build test this stuff, as I don't really have a use for it
> > > > personally. I figured if nobody's reporting bugs then probably it's broken
> > > > and nobody's noticed because nobody's using it.
> > > >
> > > > > > I get new copies of the kernel when there are releases and test them
> > > > > > frequently to make sure everything is still working as expected.
> > > >
> > > > I'd actually expected it to be broken, but I guess we managed to avoid
> > > > screwing things up ;)
> > > >
> > > > > > For us we just don't care about XIP. I mean if someone did push it
> > >
> > > I don't care XIP either, and IMHO the XIP's maintenance effort is much
> > > bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> > > macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> > > code readability will be much better.
> > >
> > > Or sending out a similar XIP deprecation patch to see whether there's
> > > any complain ? ;)
> > >
> > > > > > through to fruition, I'd also test and use it, but I urge you please
> > > > > > do not deprecate this. While it's sometimes needed a bit of a
> > >
> > > +1 for urge the upstream please do not deprecate NOMMU.
> > >
> > > Besides the soft(FPGA) core mentioned by Charles, here is another real
> >
> > And I'd like to write more about soft core: riscv is a free and open
> > ISA, this make it really good for education, for simple riscv
> > implementation or emulator. Once riscv IMA is implemented(even if MMU,
> > cache, TLB stuff don't exist), it's not far away from making linux
> > running on the FPGA or emulator. If the gain is larger than the maintenance
> > effort, I'd like to urge keeping the NOMMU support.
> >
> > Thanks a lot
> >
> > > usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> > > contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> > > core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> > > doesn't prevent users to run other OS such as threadx, zephyr or nommu
> > > linux on the small core. In fact, I sucessfully brought up nommu linux
> > > on the small core. I didn't just send out the patches in time during this
> > > dev window duo to my personal career reason(I spent the time on hunting
> > > for a new job)
> > >
> > > I plan to send out NOMMU related patches once 6.9-rc1 is out.
>
> As is promised, the NOMMU improvement patches are sent out
> https://lore.kernel.org/linux-riscv/[email protected]/T/#t
>
> Thanks
>
> > >
> > > > > > creative build to get everything working, I've never needed to patch
> > > > > > anything in the kernel beyond patching in a custom console for serial
> > > > > > output.
> > > > > >
> > > > >
> > > > > Hey Charles,
> > > > >
> > > > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > > > Having FDPIC psABI to be merged upstream could also probably be a
> > > > > positive point toward a better NOMMU support.
> > > >
> > > > Ya, that's probably the right way to do it. Touching anything in the psABI
> > > > is pretty miserable, though, so I don't really want to force people to do
> > > > it...
> > > >
> > > > > > I am happy to discuss the possibility of me and or one of the other
> > > > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > > > but so far we've just been very well serviced by the current NOMMU
> > > > > > Linux setup.
> > > > >
> > > > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > > > users for new releases then.
> > > >
> > > > Having more upstream interaction from users is always appreciated, that's
> > > > the best way to prove people are using the code. If you guys have the time
> > > > it'd be great to get this into some sort of CI, ideally running on some real
> > > > platform.
> > >
> > > As above, I'd also like to step up on the NOMMU stuff, at least test
> > > nommu on milkv duo's small core. And can be seen from my git commit
> > > histotry, I was active, and I belive I will still be active on riscv linux
> > > kernel development.
> > >
> > > >
> > > > > Thanks,
> > > > >
> > > > > Clément
> > > > >
> > > > > >
> > > > > > Charles
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > > > I guess I could also mark XIP as deprecated.
> > > > > > >
> > > > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > > > to support, there's far less that it does differently, the main barrier
> > > > > > > was the inability to test it which is no longer the case.
> > > > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > > > switch in the alternatives too).
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Conor.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > linux-riscv mailing list
> > > > > > > [email protected]
> > > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > >
> > > > _______________________________________________
> > > > linux-riscv mailing list
> > > > [email protected]
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, Mar 26, 2024 at 01:25:08PM -0700, Charles Lohr wrote:
> Jisheng, are you using musl or uclibc? I've been having difficulty
> getting new versions of each working with the newer kernels with
> system calls not lining up.
Hi Charles,
I tested nommu linux with uclibc, both rv32 and rv64
Thanks
>
> Also, is there a better place to ask questions about the more
> user-spacy stuff? That's really where I've been struggling to
> maintain things, keeping buildroot working when targeting RV32 NOMMU.
> Thankfully a lot of the stickiest problems have all been upstreamed.
>
> Charles
>
> On Mon, Mar 25, 2024 at 10:12 AM Jisheng Zhang <[email protected]> wrote:
> >
> > On Thu, Mar 14, 2024 at 09:02:43PM +0800, Jisheng Zhang wrote:
> > > On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> > > > On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > > > > On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> > > > > >
> > > > > >
> > > > > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > > > > for Linux, as well as some limited systems.
> > > > >
> > > > > OK.
> > > > >
> > > > > I just build test this stuff, as I don't really have a use for it
> > > > > personally. I figured if nobody's reporting bugs then probably it's broken
> > > > > and nobody's noticed because nobody's using it.
> > > > >
> > > > > > > I get new copies of the kernel when there are releases and test them
> > > > > > > frequently to make sure everything is still working as expected.
> > > > >
> > > > > I'd actually expected it to be broken, but I guess we managed to avoid
> > > > > screwing things up ;)
> > > > >
> > > > > > > For us we just don't care about XIP. I mean if someone did push it
> > > >
> > > > I don't care XIP either, and IMHO the XIP's maintenance effort is much
> > > > bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> > > > macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> > > > code readability will be much better.
> > > >
> > > > Or sending out a similar XIP deprecation patch to see whether there's
> > > > any complain ? ;)
> > > >
> > > > > > > through to fruition, I'd also test and use it, but I urge you please
> > > > > > > do not deprecate this. While it's sometimes needed a bit of a
> > > >
> > > > +1 for urge the upstream please do not deprecate NOMMU.
> > > >
> > > > Besides the soft(FPGA) core mentioned by Charles, here is another real
> > >
> > > And I'd like to write more about soft core: riscv is a free and open
> > > ISA, this make it really good for education, for simple riscv
> > > implementation or emulator. Once riscv IMA is implemented(even if MMU,
> > > cache, TLB stuff don't exist), it's not far away from making linux
> > > running on the FPGA or emulator. If the gain is larger than the maintenance
> > > effort, I'd like to urge keeping the NOMMU support.
> > >
> > > Thanks a lot
> > >
> > > > usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> > > > contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> > > > core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> > > > doesn't prevent users to run other OS such as threadx, zephyr or nommu
> > > > linux on the small core. In fact, I sucessfully brought up nommu linux
> > > > on the small core. I didn't just send out the patches in time during this
> > > > dev window duo to my personal career reason(I spent the time on hunting
> > > > for a new job)
> > > >
> > > > I plan to send out NOMMU related patches once 6.9-rc1 is out.
> >
> > As is promised, the NOMMU improvement patches are sent out
> > https://lore.kernel.org/linux-riscv/[email protected]/T/#t
> >
> > Thanks
> >
> > > >
> > > > > > > creative build to get everything working, I've never needed to patch
> > > > > > > anything in the kernel beyond patching in a custom console for serial
> > > > > > > output.
> > > > > > >
> > > > > >
> > > > > > Hey Charles,
> > > > > >
> > > > > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > > > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > > > > Having FDPIC psABI to be merged upstream could also probably be a
> > > > > > positive point toward a better NOMMU support.
> > > > >
> > > > > Ya, that's probably the right way to do it. Touching anything in the psABI
> > > > > is pretty miserable, though, so I don't really want to force people to do
> > > > > it...
> > > > >
> > > > > > > I am happy to discuss the possibility of me and or one of the other
> > > > > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > > > > but so far we've just been very well serviced by the current NOMMU
> > > > > > > Linux setup.
> > > > > >
> > > > > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > > > > users for new releases then.
> > > > >
> > > > > Having more upstream interaction from users is always appreciated, that's
> > > > > the best way to prove people are using the code. If you guys have the time
> > > > > it'd be great to get this into some sort of CI, ideally running on some real
> > > > > platform.
> > > >
> > > > As above, I'd also like to step up on the NOMMU stuff, at least test
> > > > nommu on milkv duo's small core. And can be seen from my git commit
> > > > histotry, I was active, and I belive I will still be active on riscv linux
> > > > kernel development.
> > > >
> > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Clément
> > > > > >
> > > > > > >
> > > > > > > Charles
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > > > > I guess I could also mark XIP as deprecated.
> > > > > > > >
> > > > > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > > > > to support, there's far less that it does differently, the main barrier
> > > > > > > > was the inability to test it which is no longer the case.
> > > > > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > > > > switch in the alternatives too).
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Conor.
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > linux-riscv mailing list
> > > > > > > > [email protected]
> > > > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > >
> > > > > _______________________________________________
> > > > > linux-riscv mailing list
> > > > > [email protected]
> > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
Sorry, if you don't mind clarifying, do you know which version you
used, where you got it, and if you had to apply any patches?
Charles
On Tue, Mar 26, 2024 at 6:28 PM Jisheng Zhang <[email protected]> wrote:
>
> On Tue, Mar 26, 2024 at 01:25:08PM -0700, Charles Lohr wrote:
> > Jisheng, are you using musl or uclibc? I've been having difficulty
> > getting new versions of each working with the newer kernels with
> > system calls not lining up.
>
> Hi Charles,
>
> I tested nommu linux with uclibc, both rv32 and rv64
>
> Thanks
>
> >
> > Also, is there a better place to ask questions about the more
> > user-spacy stuff? That's really where I've been struggling to
> > maintain things, keeping buildroot working when targeting RV32 NOMMU.
> > Thankfully a lot of the stickiest problems have all been upstreamed.
> >
> > Charles
> >
> > On Mon, Mar 25, 2024 at 10:12 AM Jisheng Zhang <[email protected]> wrote:
> > >
> > > On Thu, Mar 14, 2024 at 09:02:43PM +0800, Jisheng Zhang wrote:
> > > > On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> > > > > On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > > > > > On Tue, 27 Feb 2024 01:11:41 PST (-0800), [email protected] wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > > > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > > > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > > > > > for Linux, as well as some limited systems.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > I just build test this stuff, as I don't really have a use for it
> > > > > > personally. I figured if nobody's reporting bugs then probably it's broken
> > > > > > and nobody's noticed because nobody's using it.
> > > > > >
> > > > > > > > I get new copies of the kernel when there are releases and test them
> > > > > > > > frequently to make sure everything is still working as expected.
> > > > > >
> > > > > > I'd actually expected it to be broken, but I guess we managed to avoid
> > > > > > screwing things up ;)
> > > > > >
> > > > > > > > For us we just don't care about XIP. I mean if someone did push it
> > > > >
> > > > > I don't care XIP either, and IMHO the XIP's maintenance effort is much
> > > > > bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> > > > > macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> > > > > code readability will be much better.
> > > > >
> > > > > Or sending out a similar XIP deprecation patch to see whether there's
> > > > > any complain ? ;)
> > > > >
> > > > > > > > through to fruition, I'd also test and use it, but I urge you please
> > > > > > > > do not deprecate this. While it's sometimes needed a bit of a
> > > > >
> > > > > +1 for urge the upstream please do not deprecate NOMMU.
> > > > >
> > > > > Besides the soft(FPGA) core mentioned by Charles, here is another real
> > > >
> > > > And I'd like to write more about soft core: riscv is a free and open
> > > > ISA, this make it really good for education, for simple riscv
> > > > implementation or emulator. Once riscv IMA is implemented(even if MMU,
> > > > cache, TLB stuff don't exist), it's not far away from making linux
> > > > running on the FPGA or emulator. If the gain is larger than the maintenance
> > > > effort, I'd like to urge keeping the NOMMU support.
> > > >
> > > > Thanks a lot
> > > >
> > > > > usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> > > > > contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> > > > > core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> > > > > doesn't prevent users to run other OS such as threadx, zephyr or nommu
> > > > > linux on the small core. In fact, I sucessfully brought up nommu linux
> > > > > on the small core. I didn't just send out the patches in time during this
> > > > > dev window duo to my personal career reason(I spent the time on hunting
> > > > > for a new job)
> > > > >
> > > > > I plan to send out NOMMU related patches once 6.9-rc1 is out.
> > >
> > > As is promised, the NOMMU improvement patches are sent out
> > > https://lore.kernel.org/linux-riscv/[email protected]/T/#t
> > >
> > > Thanks
> > >
> > > > >
> > > > > > > > creative build to get everything working, I've never needed to patch
> > > > > > > > anything in the kernel beyond patching in a custom console for serial
> > > > > > > > output.
> > > > > > > >
> > > > > > >
> > > > > > > Hey Charles,
> > > > > > >
> > > > > > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > > > > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > > > > > Having FDPIC psABI to be merged upstream could also probably be a
> > > > > > > positive point toward a better NOMMU support.
> > > > > >
> > > > > > Ya, that's probably the right way to do it. Touching anything in the psABI
> > > > > > is pretty miserable, though, so I don't really want to force people to do
> > > > > > it...
> > > > > >
> > > > > > > > I am happy to discuss the possibility of me and or one of the other
> > > > > > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > > > > > but so far we've just been very well serviced by the current NOMMU
> > > > > > > > Linux setup.
> > > > > > >
> > > > > > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > > > > > users for new releases then.
> > > > > >
> > > > > > Having more upstream interaction from users is always appreciated, that's
> > > > > > the best way to prove people are using the code. If you guys have the time
> > > > > > it'd be great to get this into some sort of CI, ideally running on some real
> > > > > > platform.
> > > > >
> > > > > As above, I'd also like to step up on the NOMMU stuff, at least test
> > > > > nommu on milkv duo's small core. And can be seen from my git commit
> > > > > histotry, I was active, and I belive I will still be active on riscv linux
> > > > > kernel development.
> > > > >
> > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Clément
> > > > > > >
> > > > > > > >
> > > > > > > > Charles
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <[email protected]> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > > > > > I guess I could also mark XIP as deprecated.
> > > > > > > > >
> > > > > > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > > > > > to support, there's far less that it does differently, the main barrier
> > > > > > > > > was the inability to test it which is no longer the case.
> > > > > > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > > > > > switch in the alternatives too).
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Conor.
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > linux-riscv mailing list
> > > > > > > > > [email protected]
> > > > > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > > >
> > > > > > _______________________________________________
> > > > > > linux-riscv mailing list
> > > > > > [email protected]
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, Mar 26, 2024 at 06:34:09PM -0700, Charles Lohr wrote:
> Sorry, if you don't mind clarifying, do you know which version you
> used, where you got it, and if you had to apply any patches?
Hi,
rv32 uclibc toolchain is based on gcc12.2, while rv64 uclibc is based on
gcc13.2
I built them with the mainline buildroot, and rv32 toolchain was built
a year ago, I forget whether there was patches applied. I may apply
patches from your mini-rv32ima repo. The rv64 toolchain was built a
month ago, no patch is applied.
Thanks
>
> Charles
>
> On Tue, Mar 26, 2024 at 6:28 PM Jisheng Zhang <[email protected]> wrote:
> >
> > On Tue, Mar 26, 2024 at 01:25:08PM -0700, Charles Lohr wrote:
> > > Jisheng, are you using musl or uclibc? I've been having difficulty
> > > getting new versions of each working with the newer kernels with
> > > system calls not lining up.
> >
> > Hi Charles,
> >
> > I tested nommu linux with uclibc, both rv32 and rv64
> >
> > Thanks
> >
> > >