Re: [QUERY]: Adding support for a platform

["Lad, Prabhakar" <prabhakar.csengg@gmail.com>]

Hi Palmer,

Sorry for the late reply.

On Tue, Nov 29, 2022 at 9:54 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 29 Nov 2022 13:40:53 PST (-0800), prabhakar.csengg@gmail.com wrote:
> > Hi Palmer,
> >
> > On Tue, Nov 29, 2022 at 8:57 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Tue, 29 Nov 2022 12:21:31 PST (-0800), Andrew Waterman wrote:
> >> > On Tue, Nov 29, 2022 at 12:12 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >> >>
> >> >> On 29 Nov 2022, at 19:28, Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> >> >> >
> >> >> > Hi Palmer,
> >> >> >
> >> >> > Oops I should have included linux-riscv to the CC list here (doing it now)
> >> >> >
> >> >> > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> >> >>
> >> >> >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org wrote:
> >> >> >>> Hi All,
> >> >> >>>
> >> >> >>> If this is not the right place to ask this question please let me know.
> >> >> >>>
> >> >> >>> So we have a RISCV platform (Renesas RZ/Five) for which we need to
> >> >> >>> adjust the TEXT_START_ADDR. So below are my queries:
> >> >> >>> * What is the procedure for upstreaming?
> >> >> >>> * Are patches accepted for individual platforms (for adjusting TEXT_START_ADDR)?
<snip>
> > Enabling the local memory (ILM/DLM) on the core is a specification
> > option and is enabled on RZ/Five SoC. I'm checking with Andes if this
> > can be forcefully disabled.
> > The only use case would be to speed up things for some slower block
> > (but said that its user application specific)
>
> If it's possible to disable this somehow that'd be great, but after
> writing up the "maybe we can context switch this" bit I think we could
> probably get away with some sort of compatibility mode here.
> Essentially: Don't allocate out of this region by default, but if
> userspace explicitly maps this region (as happens with static binaries)
> then allow it, but track those allocations and begin swapping it on
> context switches.
>
Do you think even with TEXT_START_ADDR change user space can map into LM?

> That might be a lot of work and would definitely be slow, but as long as
> other VAs can map to these PAs then I think we'd be pretty much safe --
> we'd lose read-only and execute-only permission tracking, but existing
> binaries would still run.  That would allow this TEXT_START_ADDR change
> to be just a performance thing, and we might want that as a tunable for
> distros anyway (for huge page alignment, for example).
>
Okay, I'll create a patch for the TEXT_START_ADDR change.

> A lot of that would depend on exactly how the hardware treats these
> special VAs, though.  Probably best if you just dig through the docs,
> see how this all works, and then propose some rough patches?

I checked with Andes and it looks like we cannot disable the local
memory by registers. As per Andes [0] (page 30) if the VA is Local
memory (LM) it straight aways treats it as PA and it never searches
through TLB (note there is a arrow missing in the diagram VA->PA if
LM)

[0] http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf

Cheers,
Prabhakar